Slashdot Mirror
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 "
I have done a lot of work with VAJava for NT and AIX and find it to be a good IDE. Good is very relative, since I still prefer Emacs and an xterm. Anyway, back to the point.
The best part of the VAJava IDE is the High Performance Toolkit. This allows Java classes to be compiled into native code libraries that, like classes, are dynanmicly loaded. The performance is far beyond that of any JIT compilier and you don't have to lose the flexibility of java classes. There are some major complaints with the software (mostly lack of virtual machine control and release-to-release binary compatability) but its very promising. Personal experience places a JIT compiler at around 1/3 the speed of C in many applications (Networking, file seeking, data crunching, etc) The High Performance code runs around 1/2 the speed of C. This would be very helpful since I use Java on very CPU intensive personal projects. Hopefully they can work out the kinks if it is incorporated into VAJava for Linux
--- Linux... a college project gone horribly right
> NT can run Microsoft IIS (not IE4, that's a webbrowser), as well as a few other webservers, >with Linux, Apache is pretty much the only game in town
What are you smoking?
zeus
boa
gn
wn
roxen
aolserver
to name a few, not to mention using squid in conjunction with apache, which is a big win for static content. not to mention they compared CGI with ISAPI, not, say, mod_perl or mod_jserv, etc.
As I recall, the real Diogenes went looking for an honest man.
D106ene5 just went trolling.
No, Java was not invented "to kill Microsoft". Actually the original intent was as a language for embedded but downloadable apps, such as in set-top boxes, cell phones, etc. These can have all sorts of different processors, so portability is an issue. Yes, open source makes portable executables less of an issue in the desktop/server environment, but no settop box user is going to recompile the latest rev to the software that just downloaded from the cable or satellite link.
IBM doesn't use Java "to fight Microsoft". THey use it because they have a half dozen different architectures to support (PCs, RS/6000, AS/400, System/390, etc.) and because it's a damn good development language in its own right.
> "Building apps in Java since the v0.9xxx days".
Okay, so you can type "javac" or "make". That's a little different from actually designing and coding software.
-- Alastair
How Sun got their heap allocator to be as fast as C++'s stack allocator is pretty simple, more or less. (read their white papers and data sheets for more). Basically, you have a big 'stack' just for objects, and when you get to the end, you go back to the start, and for all the old (dead) objects there (often most of them) you just clear them out, and if an object is still live then you move it to a different block, where objects are expected to last longer, and has a more complicated algorithm to keep things tidy. Of course, if you're allocating huge numbers of objects that last a long long time, then Sun's method will slow down... though any method would (but if you know you're going to do this, you could make the heap bigger)
PS Your code example is just dead code, so a C compiler would just drop that code. HotSpot will also do this optimisation.
For the lazy:
t ml
HotSpot Performance Engine:
http://java.sun.com/products/hotspot/
Developer Connection:
http://developer.java.sun.com/developer/index.h
(you'll have to sign up)
æeee!
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.
Are there any performance comparisons out there between NT JITs and Linux JITs? I keep hearing that NT kicks Linux in the pants in this dept and would like to see some proof.
Visit the Perl Search Engine at www.linuxextreme.com
If IBM's Visual Age for Java is anything at all like IBM's Visual Age for Smalltalk, you don't want it anywhere near your computer! VAST is far and away the worst commercial program I've ever had the profound displeasure not to be able to avoid installing; it is worse than Microsoft Windows.
Unless IBM can demonstrate to me that VAJava is going to be developed by a completely different group of people than the ones who inflicted VAST upon the world, I'm going to do everything in my power to stop this abomination from dirtying Linux's good name.
We never hear about these packages being developed
for java, in java.
There would be no reason whatsoever to have to
wait for Visual Age "for linux" or for there to
be JBuilder "for Win32".
What was that main thing that made java so great
again?
-fb Everything not expressly forbidden is now mandatory.
We were incredulous at the how slow the IDE was. We were running on P-II 333's, completely state of the art at the time, and it was taking significant time just to open some dialog boxes! I'm used to NT being slow on some things, but this was just ridiculous.
I don't know if this is still the case, but we eventually found out the IDE was written...not in C...not in C++...not even in Java...the thing was written in...wait for it...Smalltalk!
Object oriented is cool for some things, but it's certainly something that can be taken too far!
-Justin
BTW, I feel like I should mention that IBM was a really cool sponsor of the event. They certainly didn't skimp on anything!
If you want really nice performance under most platforms, take a look at the HotSpot JIT compiler. They say it's about 3-5x faster running stuff.
As well, there's a release candidate for the rewritten java compiler which simply kicks butt. It's orders of magnitude faster.
Get HotSpot from java.sun.com (link is on the front page) and join the Developers section (free) to get javac-ea (Early-Access compiler). It's worth the downloads...
æeee!
I tried JBuilder, VisualAge, Symantec Cafe, and Visual J++ and thought all of them were pretty awful, about as awful as the C++ and/or Smalltalk IDEs they were derived from. But, then, I'm sticking with the IDE I have been using for many years: Emacs, and it happens to be written in C and Lisp.
Pure Java IDEs are beginning to appear, however, and I think you are going to see more and more people moving in that direction over the next few years.
If an enterprise IT shop regularily uses C/C++ on the server side, I would really pity them. Maintenance is, after all, 70% of all a piece of software's costs, and C++ often encourages programming that leads to an unmaintainable quagmire.
IBM has the most to benefit from Java. They need a new language to replace the "old" stalwart business language: COBOL. Smalltalk was destined to do this - it didn't quite work out that way. Java is a scaled down attempt at achieving the same thing: bringing modern programming practicies into the enterprise.
Have you taken a look at IBM's new VM for Win32? It runs faster than most Java native compilers do. And it's 85% cross platform - meaning you'll see this on Solaris, Linux, etc. some day.
-Stu
Perhaps IBM has the right philosophy here - VisualAge *is* a time tested, usable product. Smalltalkers in droves swear by it. Even C++ people swear by it.
It's not usable by the average joe because this is not an average joe's IDE. It is an IDE by professionals FOR professionals.
This is not meant to sound as elitism. You don't have to be a rocket scientist to figure this IDE out - it really IS simple - simpler than Visual C++ or J++, in my experience.
It took me maybe 3-4 days to figure out pretty much everything about how VisualAge operated and WHY the traditional Smalltalk IDE metaphor of repository + incremental compile + packages/classes/methods layout *IS* so effective.
-Stu
Gosh, I haven't seen such idiotic claims in my entire life.
,Python, Java, TCL, or PHP, and *NOT* C/C++.
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
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.
1) if you're going to use HotSpot, read all the docs. It's quite easy to write a simple 'benchmark' that goes really slow on HotSpot. (then change about 2-3 lines and it goes 20x faster)
2) Performance really does vary a lot. Best are predominantly Java server-apps - typical speed-up is 2-4 fold.
3) Client/graphics don't change up because most of the time running for them is in the binaries, not Java byte-code. According to Java's creator, the graphics guys are spending all their time making the code faster and leaner the moment...
4) JavaWorld HotSpot article - checkout the VolanoMark scalability on Solaris - WOAH! (half way down)
5) Apps with heavy object usage really do benifit. I've seen one example with a compiler with a C++ and Java version. The Java version with HotSpot was 50% faster than the C++!
6) Garbage collection and memory allocation is amazing - hardly notice garbage collection any more, and some people reckon the object allocation (on the 'heap') is as fast as C++'s on the stack! (in C++, allocating to the stack is much faster than the heap)
7) The HotSpot code was designed to be highly portable
8) HotSpot is free to use.
9) HotSpot will come out under Sun's "Community Source liscence" in about 6 months. (enough time to patent everything?)
I'm not convinced that it is entirely a good thing if Windows-style IDEs come to GNU or Linux. If Linux starts looking and behaving simply like a more robust version of Windows, where are all the UNIX people supposed to go?
Interesting opinions, but...
Sun has not refused to open up Java. What they have done is recognized that the 5-10 year cycle for most standards body is too slow to be useful, and often results in standards that no one implements, like the full version of ANSI SQL. They also attempted to submit it as a standard, only to have the rules changed half way through the process. They have done a tremendous job of refereeing feedback from different application and tool developers, and integrating the most useful concepts in the development stream. Take a look at some of the submissions from the OMG for collections (which had a lot of SQL-specific baggage), then take a look at the JDK 1.2 implementation. Modulus' InterAgent technology submissions have had their impact on messaging, and I have no doubt that the clean breadth of JDBC was enhanced by suggestions from people who are fed up with the hassles of using tools like ODBC.
HP has not fractured Java -- yet. Personally I am far more concerned by the recent rulings in the American courts in Sun vs. Microsoft than I am about HP. As much as I like HP's hardware (and HP-UX), the only place I've ever seen software developed for their systems were for telecom companies and as data-capture managers on manufacturing floors.
IBM is only one of many players in the Java world. They rightly recognized that providing easy front-end access to their big iron was the best way to maintain and possibly grow the sales of mainframes and large AIX systems. If you think they just did it for publicity, you are sadly mistaken.
Red Hat, et al are only relevant if you think Java was created for the sole purpose of "killing" Microsoft. If that's all you see in Java, it's no wonder you think it's dead.
Slow. Buggy. Ugly. You must be playing devil's advocate, because you are the only person I have ever heard make such statements about Java. I work with broad-based teams with experience in C, C++, messaging systems, transaction processing, mainframes, yada, yada, yada -- every one of them was very quick to see the benefits of Java. The closest I've heard to your views were from a Smalltalk programmer who tells me that language has had Java's functionality for several years now.
As for the server side you can use C/C++ or whaterver else. But with C/C++ you need to rely on non-portable libraries to get threading support, and I can tell you from personal experience that there are some pretty serious compatibility issues with pthreads implementations from Sun, IBM, DEC/Compaq, HP, and Linux. Win32 is a completely different code branch. The development, testing, and maintenance costs of such software compared to the issues of "performance" with Java are more than adequate to cover the cost of massive 8- and 16-way SMP boxes which more than compensate for any performance differences.
The only issues I've encountered with write-once run-anywhere Java have been with the GUI, not with the code layers application servers get written in. The sole exception to that is JDBC which can be a dog if you don't have a backend database that will let you take advantage of durable SQL statements, or if you don't have a database/driver that supports multiple connection sessions from a single client process.
You are right about Java not being used to develop "applications" if you mean desktop automation tools (word processing, spreadsheets, etc.) But if you think those are the only "real" applications, I suggest you contact some people working with large systems such as those in the telecom, manufacturing, or other industries where a "small" application only deals with a couple hundred concurrent users. Desktop PCs and workstations are just the front end to that world, they don't define it.
I do not fail; I succeed at finding out what does not work.
Started with Java a few years back and I really love the language.
I've just never seen an application for it.
Dunno if Sun helped kill it, or if the hype outshined it's ability. But as a web application developer I've found zero use for Java.
PHP3, Perl and stock html are the only way to go.
I don't mean to bash Java the language, I just really would have liked to have seen it go from being Sun's Java to a Useful Java.
Anyway, if you're into Java and have never used Visual Age I'd _highly_ recommend it.
I've used just about all the Java IDE's and VAJ was the best when it came to glueing together applications visually.
You can wire buttons to text boxes that take input from function calls on other visual elements(like a select box), all without editing code.
Very nice. Get's you into the mindset of writing independant functions and just visual pulling them together.
Only down side was that IBM took their sweet time keeping up with the Java revs.