The "Return" of Java Discussed

An anonymous reader writes "Following on from the marvelous recent James Gosling interview highlighted in Slashdot last week, it would seem that a renewed momentum is building up for his cross-platform creation, if this editorial is anything to go by. It's called 'Java is Back!' But did it ever go anywhere?"

Comments

There has been some good alternatives

[after]

wxWidgets (my favorite) and wx.NET
Mono
Cocoa# and Gtk# (recentely kn /.) .NET

Java is slow, obeist, and heavy.

Re:There has been some good alternatives

[LizardKing]

But how many companies do you see requiruing wxWidgets experience? Not to knock it as a cross platform development toolkit, but rightly or wrongly it's overlooked by virtually every company I've ever worked at. The exception is my current employer, where it was evaluate along with Qt and Java as a means to write cross platform GUIs. Java won, as C++ proved far too troublesome on a previous project.

.NET is actually a back handed compliment to Java. Java was so good that MicroSoft had to clone it. With Mono now at version 1.0, then perhaps C# is in a position to threaten Javas cross platform crown, although perhaps not without Windows Forms support.

Re:There has been some good alternatives

[Coppertone]

Java is "slow" because Sun has give us a brain dead GUI components. If you are looking at server side running things like EJBs, JSPs and servlets it is just as competitive as .NET framework.

There are a lot of pending improvement on Java GUI front, like Eclipse Rich Client Framework using SWT and hopefully it will not be "slow" anymore

Re:There has been some good alternatives

[Anonymous Coward]

Yawn. The 'Java is slow, obese and heavy' arguments are poor, out of date and largely inaccurate. Java's popularity on mobile phones suggests it is hardly a performance bottleneck, nor is it too demanding for memory.

When Java first came out, a large number of 'web hackers' and inexperienced programmers flocked to the language and produced applications that were often very weak. The easy access to such a flexible toolkit encouraged first time coders to undertake projects beyond their skills. Even experienced teams of developers found it took a while to get to grips with the issues involved in the new environment. The result was the inevitable disillusionment following the hype. Expect C# to go through a similar slump as people realise it doesn't solve all your problems.

However, Sun have done a stunning job in evolving Java, and developers who have taken the time to understand it have been producing impressive software for some time now. The latest version is powerful, fast and addresses an enormous range of requirements that make developing software very much more efficient.

There will be a lot more about Java in the news this year. Tools are being developed for everything from screensavers to MMORPGs, so why not take a second look before rehashing old predjudices?

Re:There has been some good alternatives

[redsolo]

Im amazed that MS (or other firms) have managed to let these rumors become facts. Java is not slow, at my last job we created an image viewer for professional photographers which was running on Java. The system had no problem showing 2000 thumbs (not at the same time, but scrolling was instant), zooming into 10mbs images was a breeze, you could play with the mouse buttons and it would instantly zoom to the 1:1 layer and back again. And this is something that Java has been known to be very bad with GUI and images. But we managed to pull it of anyway, and it was even quicker than the defacto industry standard application, which was written in C++.

So, please dont come with those crap arguments, because they are not true.

But what is true; c++ will always be faster than java, .Net might be (but thats because of the infamous shortcuts than only MS ppl know of). But is that the really point, when you are creating desktop applications? If you want speed, try develop a desktop app in Assembler. Now it will be the fastest around, but probably look like crap.

What must be really annoying, is that .NET has borrowed so many classes from Java so they should call it J--.

Re:There has been some good alternatives

[bmj]

With Mono now at version 1.0, then perhaps C# is in a position to threaten Javas cross platform crown, although perhaps not without Windows Forms support.

Doh!

Re:There has been some good alternatives

[Randolpho]

.NET is actually a back handed compliment to Java. Java was so good that MicroSoft had to clone it. With Mono now at version 1.0, then perhaps C# is in a position to threaten Javas cross platform crown, although perhaps not without Windows Forms support.

Where C# is most threatening to Java, Windows Forms not as relevant: C# frankly makes Java look stupid with its properties syntax. Properties are like portions of the EJB properties specifications, only without all the silly get/set coding conventions... it's built right into the syntax and the engine takes care of mapping methods for you. This makes it easier to build and maintain COM/Bean like persistent property-bearing objects. *That* is where C# will beat Java. Alas that Java 1.5 -- er... Java 5.0 -- doesn't address this issue.

Re:There has been some good alternatives

[LizardKing]

I guess you're referring to Gtk# as an alternative to Windows.Forms. That's not really going to help, as the majority of C#/.NET coding is going to be targetted primarily at Windows, where Gtk# is not going to be the first choice.

I did notice in the comments for the linked article, that Miguel mentions work is underway on Windows.Forms support for Mono. That would be quite an achievement, and one that would *really* make Mono a viable cross platform alternative to Java.

Return of Java

[LizardKing]

It's strange how so many people say "Java is dying" or now that it patently isn't, they're saying "Java's back". If you go to any of the recruitment websites in the UK, the most popular requirement is Java Enterprise experience, hardly the mark of a development system that's been in decline ... The only explanations for this misrepresentation of Java that I encounter on sites like Slashdot and Linux Today is the following:

• A large part of the readership are students, and therefore don't really know what's going on in the software industry.
• The prepondereance of GNU fanboys means that Java gets dissed for not being Free(tm).

Discuss ...

Re:Return of Java

[Tim C]

You forgot a couple:

• despite entry level PCs now having specs along the lines of 2.5GHz processor and 256MB of RAM, lots of people on such sites are obssessed with perceived bloat
• lots of (but by no means all) people dissing Java are actually sysadmins, rather than programmers, and do all of the coding that they do do in perl, shell script, and similar

It always amuses me when I read "Java is teh suck because it's so slow and bloated!" comments. I've been doing server-side Java development for a little over 4 years now, and we've never had a performance problem. I use a number of client-side Java apps everyday, too, and they're perfectly responsive and usable. Sure, the same thing written in C or C++ probably would be faster - but when you literally can't tell the difference, who cares? A modern PC spends almost all its time waiting on user input or IO bound anyway.

Re:Return of Java

[LarsWestergren]

It's strange how so many people say "Java is dying" or now that it patently isn't, they're saying "Java's back".

I think a lot of the people who keep saying that Java is dying say it because they wish it was true.

And of course, if you keep repeating a lie often enough, the sheep begin to believe it. Just like on CNN, turn it on and watch a "reporter" frown in mock gravitas and ask things like "A lot of people are saying that the Kerry campaign is floundering and the Democrats are beginning to feel desperate, we ask the experts 'can anything be done, or is it already too late?'"

No one had said any of those things, but since CNN keeps saying that people say it, it becomes truth...

Re:Return of Java

[gnovos]

Sure, the same thing written in C or C++ probably would be faster - but when you literally can't tell the difference, who cares? A modern PC spends almost all its time waiting on user input or IO bound anyway.

For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.

Re:Return of Java

[16K Ram Pack]

Often, bloat just doesn't matter. It's something I wish most programmers would learn. Code has to run as fast as the job needs it to.

To generalise, a main functions of an online system needs to be optimised. But things like offline processing often doesn't. Higher priorities are maintainable and reliable code.

And what you say is right about IO. When I used to work on mainframes, our senior tech guy used to tell us to not worry about the code speed except for IO. PCs are heading that way.

Re:Return of Java

[latroM]

The prepondereance of GNU fanboys means that Java gets dissed for not being Free(tm).

The SUN's java implementation is non-free but there are other free implementations of the java standard, look at http://www.kaffe.org/ for one.

Re:Return of Java

[isorox]

the most popular requirement is Java Enterprise experience

Yeah, and 15 years of it

Re:Return of Java

[ph1ll]

I just started working at a company where user Web sessions in Orion were reaching 1 MB each.

Further investigation revealed that the code sucked. It was nothing to do with Java. A re-write brought the Web sessions down to about 100 bytes each. It is now a happy app.

Moral of the story: there is good code and bad code in any language.

(Having said that, the JVM does take an awfully long time to bootstrap...)

:-P

Re:Return of Java

[mcbevin]

For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.

Sounds nice in theory. In practice for most Java enterprise applications the memory usage is by far the biggest bottleneck. The hotspot compiler can't change this.

For example, I did a fair few speed tests working with strings in Java. For example, comparing various search and replace algorithms. The entire difference between the faster algorithms and the slower ones was how they handled the memory usage.

Strings are only a simple construct, but even with these Java is horribly inefficient unless great care is taken by the programmer to use them efficiently. In contrast, when programming C++ I can use strings paying scant regard to efficiency and know my code will virtually always be faster than any Java program doing the same thing.

Re:Return of Java

[Anonymous Coward]

For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.

Your statement is as correct as saying that Java is slow.

Java is not slow, but it's slower than a good C++ code; consider these words from Stroustrup:

When you get to percents, 10%, 50%, and such, you start arguing whether efficiency matters, whether next year's machine will be the right solution rather than optimization. But in terms of dynamic versus static, we're talking factors: times 3, times 5, times 10, times 50. I think a fair bit about real-time problems that have to be done on big computers, where a factor of 10 or even a factor of 2 times is the difference between success and failure. (http://www.artima.com/intv/abstreffi2.html)

So yes, the average C++ programmer will write not the most efficient code (as Stroustrup compares differences in a factor of 50 between bad and good codes), and the Java's Hot Spot will then easily be faster than the average code. But remember that the Hot Spot can only guess what you are trying to accomplish; a C++ compiler can actually see what you are trying to accomplish. C++ compilers are not dumb, they can do really good optimizations (when you write good code, of course).

PS: using "C/C++" in a sentence comparing them to Java will make you look like you can't differentiate C from C++. Don't be so incautious unless you wanna be flamed by the "C++ is not the same as C" crowd.

Re:Return of Java

[Xyrus]

Java is fine as long as you use it for what it was defined for.

You probably wouldn't want to use it for high-performance graphics for example, but it's great for developing most standard apps.

If you really need to eek out the last nanosecond of performance, do not use java. Java will never be able to match the speed of writing to the metal. But I don't see why you wouldn't want to use it for a client-server app where nanosecond performance isn't critical.

Java is a programming tool just like any other. Only a fool throws out a tool merely on the basis of not knowing how to use it.

~X~

Re:Return of Java

[Paradise Pete]

I've been doing server-side Java development for a little over 4 years now

See. that's the thing. If you'd have used perl you'd have finished in less than three.

Re:Return of Java

[Glock27]

Strings are only a simple construct, but even with these Java is horribly inefficient unless great care is taken by the programmer to use them efficiently. In contrast, when programming C++ I can use strings paying scant regard to efficiency and know my code will virtually always be faster than any Java program doing the same thing.

Strings are something of a weak point with Java, IMO. I'm still not sure immutable Strings were a good idea, especially since it's become a common idiom to use StringBuffer instead for performance reasons. With the latest JDK there is a yet another new string class that's like StringBuffer without synchronization - since single-thread string manipulation is the most common usage.

All that said, if you know what you're doing, you can get fine string performance in Java. There are third party classes (see FastString) that may help as well. It is too bad that this area of the language wasn't better thought out in the first place, though.

(An interesting performance enhancer worth looking into is JADE, which contains FastString. It also has interesting realtime stuff which eliminates garbage collection overhead and pauses if used properly. Lots of other good stuff too.)

Re:Return of Java

[Xugumad]

I have to disagree here. There are certainly cases where Java is faster, but they're relatively few. Lets just go through that infamous benchmark again:

Java faster than C++ benchmark

Point 1 - "I was sick of hearing people say Java was slow, when I know it's pretty fast".
Baaaad start to any analysis - always keep an open mind about the results.

Point 2 - He used G++. So this is only valid for G++, not necessarily any other C++ compiler. Which is fair, I just feel this is worth emphasising.

Point 3 - It's rapidly determined that G++ takes much longer to execute a method call, than Java does. Given this, it shouldn't be a significant suprise that benchmarks relying heavily on recursion will be slow in C++.

For example, rewriting the Fibonnaci benchmark to use a for loop instead of recursion give a 600-times speed increase:

http://developers.slashdot.org/comments.pl?sid=111 205&cid=9436176

Rewriting it into constant-space gave an almost 10 times increase over that:

http://developers.slashdot.org/comments.pl?sid=111 205&pid=9438782#9439949

Moral of the story? Java is great for method calls , but I'm not so convinced about everything else...

Re:Return of Java

[aaronl]

What is with you people? NO, IT IS NOT SLOWER IN C/C++. You are running code through a glorified interpreter running through an emulated codepath, all of which is written in C/C++. Java always will be slower, because it's always more steps from the hardware and always running in a VM.

Java code just isn't the hideously slow crap it was when it first because popular. Once the VM is up, it runs quite snappy save for some of the older and trashier widget toolkits. BUT, it still takes some time to load the VM on my 2GHz+ machine, and still takes too much memory (>16MB for the VM), and that's still no good.

The C/C++ code you've worked with is either just plain bad, or you don't know what to look for. I can always optimize my code to be faster than equivalent Java.

Write your Java code because it's the best choice, not because for the sake of being a language bigot. Java has it's uses, C/C++ has it's uses, and so does Assembly.

Re:Return of Java

[Fweeky]

"Higher priorities are maintainable and reliable code."

Which is why so many people develop with dynamic languages. Bloat isn't just at the runtime side of things; it's at development time too.

Re:Return of Java

[YetAnotherAnonymousC]

Geez. I guess you've never tried running a non-trivial web application on a webserver where your Tomcat only gets allocated 64mb RAM (and where every extra mb costs you $$$ per month). Admittedly the idea that Java is slow usually comes from people using Swing which isn't an issue for server-side applications.

Well, problem #1 is using Tomcat on a "non-trivial" production application. If you have to go free, Resin and Jetty are both more performant.

Re:Return of Java

[j3110]

And you just tell me what kind of graphical development environment works better in 256M of ram. X+Gnome+Daemons+kernel eat up most of my memory. I've done tests limiting Eclipse's memory with -Xmx. You can usually get it to run in 5M. AIM uses more memory than that, and Eclipse is an IDE. Set up the VM properly. JNLP/WebStart has tags for this. Most of the VM gets put in swap after JIT, which leaves pretty much only the heap and code to consume memory.

If you're restricted to 64M, your hosting solution is obviously for trivial web applications. RAM is cheaper than your paycheck, unless you live in a 3rd world country. Where I work, we have a pretty trivial web application, and I throw about 2Gig of RAM at it because I want to keep as much data in memory as possible for response times.

Re:Return of Java

[mcbevin]

The point is that in C++ and most other languages I can use the standard string class quite happily and its efficient and does all I need. In Java this simply isn't the case.

Isn't it rather pathetic that something like your example of

out.writeln("Cheese is "+good?"good":"bad")+"!");

is a 'bad thing' to do in Java? Personally I find it the natural way to do things, and much nicer than your second example. I hardly think I'm alone in this. Virtually all languages use the former idiom as opposed to the latter (or have an even nicer syntax). If you find the former not nice, I could suggest:

String cheeseType = (good?"good":"bad);
out.writeln("Cheese is " + cheeseType + "\n");

The String API isn't too shabby. It's much better than being forced into writting your own routines, or having to include 3rd party libraries to achieve the desired effect, which is the case with most compiled languages.

Huh???? C# provides a nice string class. So does C++. They're essentially Java's competitors, so no idea where you're coming from there.

Re:Return of Java

[Fweeky]

Sure; Ruby, Python, LISP, SmallTalk, even Perl and PHP; these are dynamically typed languages, although they may also be dynamic in other ways (like with regard to run-time code generation and modification).

Not to be confused with scripting languages, which is more about a language's environment than the language itself; you can make C into a scripting language with the right tools, but you're not going to make it into a dynamic one without changing the language itself.

Request for interview

[Anonymous Coward]

Do a user driven (10 questions, you know) with James Gosling. Java/Sun takes a lot of flak these days, it would be genuinely interesting to get Gosling respond to some good questions.

Embedded Java.

[Vo0k]

Java is a nice choice for embedded platforms. It runs several times faster than on PCs (it's native for the hardware, not "emulated" through JRE), the hardware is inexpensive and can perform really sophisticated jobs. I think it may be one of major reasons for Java to take up so much.

Java powered cryptographic iButton - a chip the size of your hand watch battery (stainless steel, shock-resistant, water-resistant and several other-resistant "iButton" package) with Java support.

APIs and Libraries

[tezza]

CPAN was a real winner for Perl back in the early days of the web. Want SMTP? Net::SMTP. Want to format that email response? Text::AutoFormat. Easy templates? Template::Toolkit.

Java now has an astounding array of libraries to use these days. Look at for some good ones.

Stupid comparison

[plumby]

A "Googlefight" on, say, Java vs .NET tells us that all has not necessarily gone Java's way just recently. A "mere" 66 million "Java" hits...versus 388 million for "NET" - but that may all be about to change.

Not that it really matters, but this is one of the most stupid comparisons ever. The .NET search pulls back just about every site with a .net extension. Out of the first 10 pages, only one seems to be directly related to the .NET framework (the 4th entry is php.net! ), whereas all of the first 10 Java searches is relevant.

Move along, nothing to see here..

[CountBrass]

Seriously, this was a 100% fluff article. The foundation for the article was based entirely on the assertion that a Google for "Java" brought back far fewer hits than "NET": well no shit Sherlock- perhaps if you'd tried ".NET" instead?

The major problem Java has is EJBs: everyone in Java-land seems to think that their problem requires solving using this pile of crap. A web application with persistence- ooh we'd better use EJBs then!

A secondary issue for Java is the barrier to entry is extremely high: sure you can learn the language quickly but it's Java's libraries that add the real value. And there are an awful lot of them. I've been using Java for 10 years (yeah I developed using the AWT and cursed it every day: if it hadn't been for the AWT being so awful I'd never have thought Swing was any good). Anyway, I've been using Java for 10 years and I would hate to have to learn it from scratch today.

Re:Move along, nothing to see here..

[rmohr02]

Seriously, this was a 100% fluff article. The foundation for the article was based entirely on the assertion that a Google for "Java" brought back far fewer hits than "NET": well no shit Sherlock- perhaps if you'd tried ".NET" instead?

You'd get the same results. The '.', used in a Google search, is a shortcut for searching for a string--you can either use '"i want to find this string"' or 'i.want.to.find.this.string'. Hence, ".NET" will search for a string consisting of the word "NET" and should return the exact same results as a search for "NET".

And for anybody who doesn't believe...

[RAMMS EIN]

``Java is slow, obeist, and heavy.''

And anybody who doesn't believe this might want to take a look at why kast wasn't written in Java. People have been telling me that I am the only one experiencing these issues, that I simply don't have enough experience, or that I should take a look at modern JVMs - well, here's one example of people who tried Java and were disappointed. The same happened to many LimeWire users. The list goes on.

Re:And for anybody who doesn't believe...

[Coppertone]

Well... but the number 2 most-active project on sourceforge, Azureus BitTorrent client, is written in Java and it looks real good.

If only everyone knows how to write Java properly....

Re:And for anybody who doesn't believe...

[LizardKing]

java applications are difficult to install - many users do not already have a copy of the java virtual machine installed on their machine. For these users, installing a java application means downloading and installing the java runtime, which is quite large and can be difficult to configure.

Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.

java applications start up slowly - even the smallest java applications can take several seconds to start up, since the virtual machine needs to be loaded first.

I run Java on very low spec embedded PC's, and it's no slouch there. Even if there is a couple of seconds wait at startup, the JIT compiler means a well written app will run without being appreciably slower than a "native" app once the JVM is bootstrapped.

java applications have slow, unresponsive user interfaces--- on slower machines, using java-based user interfaces can be frustrating (resizing the application window can mean taking a coffee break).

That's strange, it must be their inability to code an interface and data models in an efficient manner. I write warehouse control software, where we are dealing with vasts amount of data that must be collated and displayed to the user. Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.

java applications use a lot of memory - on most platforms, the virtual machine itself requires several MiB of memory, even for small applications that use very little memory. For more complicated applications, such as konspire2b, the virtual machine adds a lot of memory overhead. For example, kast currently uses about 1 MiB of memory when it's up and running. konspire 1.0 server (written using java) uses about 12 MiB. The interesting point is that konspire2b is far more complex that konspire 1.0 server (for example, the server portion of konspire 1.0 doesn't even have a user interface).

If this is really an issue for you, then you can tweak the runtimes environment. Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.

java applications leak memory

This could be rephraed as "bad Java programmers leak memory". I have client-server Java applications that run 24x7 without leaking memory. Perhaps it's because I'm an unsually good Java programmer? Probably not, as I'm just an average one. What I don't do is immediately blame problems on the tools I use until I'm sure it isn't my lack of skill with the tools.

Re:And for anybody who doesn't believe...

[groomed]

Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.

Everything is easy when you approach it from the point of view that it doesn't actually have to work.

There are many versions of the Java environment, from different vendors, all with subtly different behaviors and ways of integrating into the environment. Not to mention that the user may be running other Java applications which depend on a particular version of the Java environment, which further complicates matters. This makes it a pain if you want to deliver an application to the user with minimal hassle.

Or, you can just mandate that the user run such-and-such version of the Java enviroment on such-and-such platform, but then you lose a large part of the write-once, run-everywhere appeal.

I run Java on very low spec embedded PC's, and it's no slouch there. Even if there is a couple of seconds wait at startup, the JIT compiler means a well written app will run without being appreciably slower than a "native" app once the JVM is bootstrapped.

Java's "slowness" has at least three components: startup time, garbage collection delays, and the huge footprint which triggers swap activity.

For server applications, none of these matter much. For interactive client applications, these factors conspire to make Java apps look very bad when compared to "native" competitors. The exception here are applications like Eclipse, which you start when you get in from work and don't quit until you're done. But for most other apps, e.g. utility apps which you just want to quickly use and close, or workflows where you switch between multiple apps frequently, Java is just not suited.

Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.

You're missing the point royally. Java isn't slow at doing grunt work. Few people would contest that. But as a platform to write desktop applications, it is a pig. The Swing UI is slow and prone to memory leaks, data interchange facilities are poor (even the clipboard functionality integrates poorly with the surrounding environment), memory requirements are completely uncontrollable.

Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.

Indeed, and that's why most Java shops pretty much only run one application on their servers.

This could be rephraed as "bad Java programmers leak memory".

The fundamental problem is that you cannot control how memory gets used. For example: the JVM allocates memory from the underlying OS in chunks which it then doles out to your app as necessary. Then at garbage collection time, the memory is reclaimed from your app and returned to the JVM. But then the JVM may or may not ever return this memory to the underlying OS. This means that even if you have a tiny application, when the user opens a mammoth 100MB document just once, the application will continue using 100MB even after the user has closed the document.

Yes, this is sort of tunable through commandline options and other properties, but then only for some versions of some implementations of the JVM. Which brings us back to the first point, that it's a hassle to deliver hassle-free Java applications. It's so troublesome in fact that some programmers choose to simply distribute a JVM along with their apps.

The bottomline is this: Java is a cool language, but it just doesn't play nice with others. It insists on reinventing everything, it insists on abstracting everything, and it insists on total control over the environment. That's fine for in-house apps or web apps, but it limits Java's adoption on the desktop.

And ultimately, I think it condemns Java to a perpetual "behind the scenes" existance, growing ever more baroque appendages in its invisible niche, until its burdensome legacy is swept away by something more open.

Re:And for anybody who doesn't believe...

[RAMMS EIN]

I am almost at the point that I'll promise not to engage in this discussion again. Ok, one more time:

``Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.''

And a 20 MB download that takes dog knows how many megabytes after installation. Also, the whole process will have to be repeated at the next release, as chances are software developed on a newer version won't run on an older one.

``Even if there is a couple of seconds wait at startup, the JIT compiler means a well written app will run without being appreciably slower than a "native" app once the JVM is bootstrapped.''

Most applications don't need a lot of speed once up and running, anyway. Startup time is a huge annoyance, to me anyway. Is it really that hard to save the compiled code, so next time the JIT doesn't have to work again?

``java applications have slow, unresponsive user interfaces--- on slower machines, using java-based user interfaces can be frustrating (resizing the application window can mean taking a coffee break).

That's strange, it must be their inability to code an interface and data models in an efficient manner.''

I don't know about your systems, but on any system I have used in the past years, user interfaces in Java apps are noticeably more sluggish than in native ones. Perhaps this is perceived performance, but arguably it's the perceived performance that matters for user interfaces.

``java applications leak memory

This could be rephraed as "bad Java programmers leak memory".''

Yes, but isn't it symptomatic of defects in the language if many programs written in it leak memory? Besides, isn't Java's garbage collection supposed to take care of things? Personally, I believe that there was an issue with old JVMs (at least on Linux) leaking memory, that has now been solved. At any rate, I think that kast's author is being more bitter than rational when he says things might be better without gc. Gc is a Good Thing, after all, memory allocation and deallocation is excactly the sort of task that machines are good at and humans are not. It can even speed up programs under some circumstances.

Re:And for anybody who doesn't believe...

[Tim C]

the huge footprint which triggers swap activity

Top 4 processes on my XP Pro machine at the moment, according to "Mem Usage" column in Task Manager:

1) JBuilderW.exe at 173,700K
2) mozilla.exe at 84,480K
3) java.exe (JXplorer, an LDAP client app) at 37,252K
4) WINWORD.EXE at 33,636K

So, with the exception of JBuilder (which is very heavyweight, there's no denying), java by no means has a "huge" footprint compared with other typical applications I use. Of course, given that I have a gig of RAM in this machine, and that RAM goes for a little more per 512MB stick than I spend on a typical Saturday night out, it really doesn't matter to me at all. But then, I do server-side stuff in Java, not client side; for that, I'd probably use C#.

Re:And for anybody who doesn't believe...

[mcbevin]

I agree with what you write in general - that the article was unduly harsh / biased against Java. However, I differ on a few details ...

Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.

We're talking about the average Joe here. The average Joe just wants to double-click the installer for a program, click OK a couple of times, and have it work. I know from experience that such a requirement can be a great hinderance to adoption of a software application. I released a program with a .NET frontend, and a large portion of end-users weren't interested in downloading the .NET framework (why this wasn't made part of XP or at least XP SP1 I don't know) and would quite happily write the program off as broken despite it having informed them they need to download the .NET framework for it to run.

That's strange, it must be their inability to code an interface and data models in an efficient manner. I write warehouse control software, where we are dealing with vasts amount of data that must be collated and displayed to the user. Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.

Swing _is_ rather unresponsive and slow unfortunately, due to it using no native widgets. This is solved by SWT, which mixes platform independence with use of native widgets where they exist. For this reason for example the popular Java IDE Eclipse (written with SWT) is much more responsive than Sun's IDE NetBeans. Swing in general is one of Java's major weaknesses (and its not 'excused' on the basis of platform independence) - not only in terms of speed but its layout managers for example are also a joke - and is the main reason why Java is used far far more for websites than application programs.

This could be rephraed as "bad Java programmers leak memory". I have client-server Java applications that run 24x7 without leaking memory.

I agree with you there, and would also add that 'very bad java programmers leak memory' while 'even pretty good C/C++ programmers leak memory. While one can leak memory in any language, Java does make it a lot easier to avoid. I have C++ programs where I've never found leaks despite a fair bit of work trying, yet I can't recall testing a single Java program for memory leaks (and I've written and tested a lot) and ever actually finding such a leak.

If this is really an issue for you, then you can tweak the runtimes environment. Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.

Unfortunately for the average user with 'just' 256/512mb RAM on their machine, thrashing is almost an unavoidable consequence of using any non-trivial Java application. For development I find 1 gig RAM is a minimum for devloping with Java, whereas for .NET development I have no problems using 'just' 512 megs.

I might also add a thought relating to the actual editorial - comparing search results for 'NET' and 'Java' is hardly an accurate comparison, given that 'NET' is liable to find a lot more pages than just those relating to .NET. That said, .NET and its C# language _is_ a huge challenge for Java. I'm hoping that this competition will cause both languages to improve and thus benefit us developers. Java 1.5 (5.0) is a great start (incorporating many much needed features seen in .NET such as generics).

Re:And for anybody who doesn't believe...

[isdfnmo]

Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.

That is SO not the point. Why the hell should a, for example, 55 year old occasional computer user need to even know WHAT Java is, let alone UNDERSTAND why they need to install it?
Surely the uppermost aim for any software engineer / developer / designer is to hide complexity from the user?
I have two roles at my work: the first is as an IT Project Manager and the second is in a Procurement role for 3rd-party software development effort (i.e. a Client). If the technical-lead on a project or a supplier ever told me that "all the user needs to do" is to "just" download and install anything (including Java) to run their application I would throw them out the door / off the project!
This is as absurd as priming your fuel pump everytime you want to drive somewhere, or calibrating your derailleur gears before you can use your bicycle.

Not acceptable!!

Re:And for anybody who doesn't believe...

[bl8n8r]

- java applications are difficult to install
This is the developers problem

- java applications start up slowly
As with any interpreted language, and has been an issue since Qbasic. Accept it.

- java applications use a lot of memory
As many applications do. 20 meg for Soundtool is ridiculous, but with a gig of ram, there is plenty left over.

- java applications leak memory
So do most other applications. If the programmer does not take heed. Again, a very broad statement having little to do with the language.

I like the portablility of Java - something most people forget about when whining and bitching about it. Think about the other applications you use, and how they suck too. The same people that wrote windows are the same ones that have an internal disgust for Java... keep that in mind as well.

Re:And for anybody who doesn't believe...

[Glock27]

And anybody who doesn't believe this might want to take a look at why kast wasn't written in Java.

One doesn't have to look far to find claims there that are simply wrong. For instance:

java applications leak memory--- java uses garbage collection to manage memory, which seems to imply that programmers don't need to think about memory management at all. However, garbage collection gives a false sense of security, and java applications can still have memory leaks unless programmers are very careful. In fact, many java applications that run for extended periods of time leak memory to the point of exhausting all system memory. These types of leaks are very difficult for programmers to isolate. In fact, memory management may be more difficult with a garbage collector than without one.

In particular, the last sentence is nonsense. Memory leaks, once identified, aren't typically hard to find in Java - and let's not forget that Java eliminates several types of memory related errors common in C/C++ programs altogether. Array overruns, wild pointers, multiple deallocations - all things of the past. Thankfully.

Some of the other objections there will go away with JDK 1.5, others might best be addressed with ahead-of-time compilation (small utilities for instance). Regardless, Java is certainly improving over time.

All that said, of course, incompetent programmers will manage to screw up in any language they're given. ;-)

Re:And for anybody who doesn't believe...

[sbrown123]

This makes it a pain if you want to deliver an application to the user with minimal hassle.


Not really. There is Java WebStart which solves this issue. Commericial products like InstallAnywhere solved this also. Old issue.


Java's "slowness" has at least three components: startup time, garbage collection delays, and the huge footprint which triggers swap activity.


Start up time is slow. It takes approx a couple seconds. Ofcourse this is a one time cost that interpreted languages go through. C# has the same problem.

Garbage collection delays? Ive never seen this as a big problem. With good coding practice (create fewer objects, reuse etc) this becomes invisible.

Memory swapping? You must have a mighty large java app or very little memory. As for java being a memory pig that is questionable since IE, mozilla, and about a dozen other apps I run on my computer consume more memory than my java apps like Azurues. Go figure.


It insists on reinventing everything, it insists on abstracting everything, and it insists on total control over the environment.


I just wrote a java app the other day that embeds an activeX control within it. Worked great. Ive written C++ apps that use Java (gcj) and it worked great. I think youll have a hard job trying to prove that strange view.


I think it condemns Java to a perpetual "behind the scenes" existance, growing ever more baroque appendages in its invisible niche, until its burdensome legacy is swept away by something more open


Java is already open. Go look at projects like GNU classpath or Kaffe. Javas invisible niche is kinda hard to miss since it covers most IT departments here in the United States and abroad. A bit hard to miss. You can go to SourceForge and see that it is currently almost exceeded the number of C and C++ apps.

Your example more fits C# at its ilk which has had very slow adoption.

Re:And for anybody who doesn't believe...

[Zardoz44]

Maybe someone should work on fixing those things that encourages most people to write java improperly. If most people are using it incorrectly, then that points to issues with the language that need to be resolved.

Re:And for anybody who doesn't believe...

[BattleTroll]

"Yes, but isn't it symptomatic of defects in the language if many programs written in it leak memory? "

No, it's not symtomatic of a bad language, but that a lot of programmers don't know how to properly manage their objects. Whenever I'm called over to look at a java memory leak it's one of two things - people put hard references in static containers that never get cleared, or they initialize objects with circular reference that don't unwind properly. Blaming Java for bad programming is just wrong.

People often use garbage collection as an excuse to be lazy. "I don't have to worry about it, the garbage collector will take care of it". I'm sorry to say, garbage collectors are not not the silver bullet to bad programming.

Re:And for anybody who doesn't believe...

[sbrown123]

For Windows perhaps. But if you're going to confine yourself to Windows, why bother with Java?


Java Web Start, atleast the one from Sun, is available on SPARC, Solaris X86, Linux, Mac OSX, and Windows.


You should compare a Java text editor to a native text editor


Well, if you take out the virtual machine Java would be about equal or better. Now you probably say thats not a fair comparison and I cant do that. But those Java crazy's are working on a single VM for multiple apps targetted for release 1.6. You can do this currently yourself too. I did this recently where I have two java apps launched from a single VM.


but, again, if you're going to tie yourself to a specific version of a VM on a specific platform, why use Java at all?


Are you talking end user or programmer? As a programmer, I can write in Java and know it will run on multiple platforms.

End users dont need to worry much about this. Recent versions of Suns java jvm updates itself. Since java is backwards compatible this means your incompatibility version issue is not really an issue.


I think that the fact that you felt the need to escape from Java and use an ActiveX control is all the proof that's required.


The activeX control was an Internet Explorer browser. Since I didnt feel like writing Internet Explorer again in Java it seemed like the smart thing to do. Your original argument was that Java apps did not play nicely with native ones which I proved incorrect.


Like COBOL, yes.


Yep. Only difference is Java apps are growing in numbers whereas theres often no new Cobol apps.

Re:And for anybody who doesn't believe...

[sbrown123]

I find it utterly hilarious that people say that Swing proves Java is fast, because the really fast parts aren't written in Java.


Swing is called a light-weight gui since it has no native peers. This means there are no native widgets in otherwords. Whoever said Swing is fast?

Azurues uses SWT. SWT is not Swing. SWT uses native widgets. SWT is generally faster than swing because of this.

BUT what people dont get is why Swing exists. SWT, although faster, operates differently on different platforms and looks different. Windows widgets look different than GTK or Qt based ones. SWT problems is the same as any other cross-platform gui like WxWindows. Swing though always looks the same no matter what the platform is. This means Swing apps look and operate the same no matter what the platform.

Re:And for anybody who doesn't believe...

[sbrown123]

As I already stated if you want native look-and-feel widgets go with SWT (or even AWT) instead. One mans fortune is anothers loss. You have to pick.

False arguments of past not valid

[essreenim]

People thought it was going away because of all the stupid people saying 'Oh, c++ is much faster'
when in fact Java uses allot of native code that is actually compiled c code. Its often very fast.

Re:False arguments of past not valid

[Glock27]

A Java virtual machine IS a c++ program. The comparisons are illogical.

Really? What about gcj, TowerJ, Jet and other native Java compilers? There is nothing preventing Java from being compiled to straight machine code using traditional ahead-of-time compilation. The stricter semantics of Java compared to C++ permit further optimization, as is the case with Fortran also, for instance.

If a Fortran compiler were written in C++, would that still mean generated executables couldn't be faster than C++ at numeric code? No.

Runtime profiling/optimization is a more complex topic, but in principle (and apparently in practice) there are cases where it is faster than ahead-of-time compilation. I think both approaches have merit.

I usually like to make this point 2-3 times when it comes up on slashdot once per month.

Repetition doesn't make it any more correct.

Source critique

[Kingpin]

One of the first things I was taught in college, was to be critic of the sources I based research on.

In the world of WWW, it seems that each and every article and blog entry can be used as reliable fact. "He wrote it, it must be true". If some nerd posts that language X is the best, and those who use it are really really smart (case in point Paul Graham/Pythong) - that really doesn't make it come true. Same goes for Java "dead or alive" etc. etc. (Naturally, we all know that BSD is in fact dying - this is the exception).

Is there a Sun campaign going on?

[Scarblac]

For quite a while, when Sun was mentioned here, it was often in the context of "they're dying, no new research, no future, no idea of how to compete with Linux", and things like that. I think the height of that was this article, which actually talks about who caused "the fall of Sun".

Now in the last two weeks, we see a steady flow of Sun-related articles. Java is being promoted (this article, and this two weeks back), there is news on Solaris ("Linux apps on Solaris", "Solaris coming to Power architecture"), there have been bits about their cool Sun Rays on Linux, their R&D with the chips without connectors, and rumours that they could buy a key player, Novell. There's also Looking Glass.

All in 11 days or so. It seems someone is screaming "Hey Slashdot, we're really alive!". You'd almost expect them to sue SCO next week just for the attention...

Java 1.5 should help things.

[Anonymous Coward]

Java is a great language that people avoid because it's a pain in the ass.

Java 1.5 goes a long way to help that, what with iterators, autoboxing and such.

For those who haven't been looking at Java lately

[Coppertone]

Azureus: http://sourceforge.net/projects/azureus/
Eclipse project: http://www.eclipse.org

Java keeps quiet

[16K Ram Pack]

One problem is, no-one much hears about it. Sun rarely seem to trumpet what they are doing with it.

I don't do Java, but from what I've seen, it doesn't change much, and where it does, it adds to what was there before. That is IMO a good thing, that developers aren't sitting around poring over documentation, but are productive instead.

(One reason for not doing Java is the small number of companies doing Tomcat hosting).

Keyword being: Enterprise

[Moraelin]

Java is pretty popular on the server side, but client side it was always one monumental flop.

As applets go, for example, nowadays the whole program-inna-browser market is owned by Flash, followed by ActiveX. And for good reasons.

Starting with the fact that Java 1.0 was indeed a slow piece of crap for anything but the most trivial applets. Try displaying a complex table without a JIT, and you were talking about response times you could measure with a stopwatch, not with System.currentTimeMillis().

The initial lack of support for packing everything in a jar didn't help that cause either. Downloading 50 classes as separate files isn't particularly fast. And that's a very small project.

And for all the multi-platform hype, wasn't particularly portable either. If you tried running even a trivial AWT applet on different platforms, you wouldn't even get the same events. Or for something which required you to give a size in pixels on the web site, you wouldn't even get the same font sizes.

And by the time it caught up... meh. Flash is _still_ the better choice.

Not the least because of download size. Sun now includes all the crap they could think of as standard libraries. Do I need an XML parser to make a simple game applet? Not really, but Sun wants my users to download that crap anyway.

(No, it's not a made up problem. I've had modem users tell me literally "whoa, I'm on dialup. Is there some smaller version I can download?")

That's just a small slice of the many ways in which Sun started it on the wrong foot.

Re:Keyword being: Enterprise

[Azghoul]

Good to see your slowing moving back down the mod chart... "Client side... was always one monumental flop" is pure myth. It's interesting that you seem to think "client side" means "in a browser window".

Run Eclipse sometime.

Re:Keyword being: Enterprise

[Sunspire]

Eclipse is great, but no thanks to Sun. IBM went ahead and developed their own native widget because it was painfully obvious to everyone with eyes in their heads that both AWT and Swing were crap. Sun's been bitching and moaning ever since and they still don't get it.

With the exception of Eclipse and Azureus (both using SWT) Java on the desktop has been an abysmal failure. If it was up to Sun it would have been dead and buried a long time ago. There are however a few things that could revive the Java desktop platform:

1. Open Source Java, allowing it to be distributed with Linux.

2. Allowing bundling of the JRE with end user applications, you just can't expect users to download it themselves. If you believe that you just haven't spent enough time with end users.

3. Be ready to make some hard decisions or watch Java rot from the inside. What the hell is up with the ridiculous "generics" implementation, now we're stuck with this autocasting-lite crap for the foreseeable future because Sun didn't want to modify the VM even a little. Very shortsighted of them.

However Sun won't do it, because there's no profit in it for them. However that's nothing new, it seems like everyone else is making money with Java except for Sun. I predict that in a few years IBM will be the defacto Java driver.

Re:Keyword being: Enterprise

[Moraelin]

What did you want me to do? Write a whole tome worth of everything that ever was wrong with Java client side? I did say "That's just a small slice of the many ways in which Sun started it on the wrong foot."

Believe it or not, I've been in client side application projects. I also have Eclipse open right now.

In fact, Eclipse is the prime example of how Sun started on the wrong foot. SWT (the widget set used by Eclipse) is IBM's work, while AWT and Swing are what Sun had in mind. The words "dumb and dumber" come to mind, when I think about AWT and Swing.

Want one thing that an actual client complained about? We had to program the same very small app in C _and_ Java, on Windows, Linux _and_ MacOS. Well, the whole package were more apps, but this was the only part which had to run on all desktops.

The client's first comment? "Whoa! Why does the Java version need 16 MB of RAM, when the C one is less than 1 MB?"

Another project was a bigger Swing "thick client" database program. In Swing. You know what the first complaint was? The look and feel. Inconsistent fonts, inconsistent keyboard shortcuts, etc. Sun's "Windows" Look and Feel is a sick joke. We ended up doing more work to write our own look and feel, just to get the program to look like a native app.

Yet another way in which SWT got it right, while Sun screwed up.

The second complaint? Performance and memory use. 'Nuff said.

Also, believe it or not, bigger companies have tried moving to Java on the desktop. It was every company's wet dream to suddenly only have to maintain one version, and work on every single OS. Some of which they didn't even support before. Everyone tried it.

E.g., Corel at one point wanted to move their whole office packet to Java.

Why do you think Microsoft got so scared and wanted to kill Java? Precisely because of this. It looked like all of a sudden everything will be multi-platform, and the "but this and that runs only under Windows" advantage will evaporate over night.

What happened to all those projects? They flopped. They ended up slow, bloated and more unstable than their Windows counterparts. So everyone moved back to C/C++.

If that doesn't count as a monumental flop, I don't know what does.

Java is not back.

[Cyberax]

It's just a marketing.

Java language has stagnated in about 1999 with the release of J2SE 1.2 (dubbed Java 2); new J2SE 1.5 (Java 5) is just a cosmetic change of language (yes, I consider current implementation of generics/annotations to be 'cosmetic').

It's quite OK to be conservative, but you can't conquer the world of IT being conservative. Java's position on server-side is still pretty firm, but desktop apps in Java (apart from Java IDEs) are non-existant.

And Microsoft's position on server-side is strengthening. So Microsoft will prevail if nothing changes in the recent future :(

Re:Java is not back.

[LarsWestergren]

Java language has stagnated in about 1999 with the release of J2SE 1.2 (dubbed Java 2)

Oh, what BS. Like that is the only thing that has changed .Java has become big enough to come in three different version, enterprise, standard and micro edition. The micro edition is extremely common in mobile phones, enterprise very common in banking etc.

Some of the new things in Java 1.3:
Java Naming and Directory Interface (JNDI), 20% faster RMI serialization, improvements in AWT/Swing/JavaSound, security enhancements, HotSpot optimization of client and server VMs.

In Java 1.4:
Secure Sockets and HTTPS, IPv6, cryptography extensions, LinkedHashMap, NIO (FileChannel, Non blocking IO), builtin regexp and logging (though there are even better open source libraries for those), assertions, XML processing, hardware acceleration of Java2D, image I/O framework, java Web start, Unicode 3.0 Support, Currency class, Accessibility improvements, Math improvments, Itanium support

In Java 1.5:
Generics, enhanced for Loop (for each), autoboxing/unboxing, typesafe enums, varargs, metadata annotations, class data sharing (improved VM startup time), launching apps under inetd in unix/linux, loads of security enhancements, Unicode 4 support, hyperbolic transcendental functions (sinh, cosh, tanh), cube root, base 10 logarithm, AMD Opteron support....

Sun is not letting MS win without a fight.

Re:Java is not back.

[Baki]

No it won't. Server-side programming (i.e. "enterprise") means backwards compatability is very important. MSFT cannot afford to break it in .NET either.

SUN has done an amazing job in extending Java even to include generics without breaking backwards compatability. Yes it did not lead to the solution that is technically and internally the most efficient (it would have required changes to the JVM), but the developer is not affected. Internally it is solved by typecasts, but who cares? The compiler, it cares and verifies and tat is what matters. .NET is years behind and plans to bring similar features only in 2007 (generics). It remains to be seen if they can do it without breaking backwards compatability. They already have a very hard time to convince their current developers to switch to .NET, they cannot afford to make their developers have to migrate once more in the next 10 years. .NET being so poorly designed I truely wonder if they can improve it without disturbing compatability. I cannot see it being a threat.

I work in a large company, and all new development is done 100% in Java (except the mainframe parts, in PL/1 but that is declining rapidly). .NET would only be considered for fat client GUI's which used to be done in MFC. So even if .NET becomes a success, it will only replace parts that were already done in MSFT technology before, it has zero chance on the server side.

Re:Java is not back.

[flibberdi]

I wont complain too much regarding the j2ee (or even j2se), but j2me..... I am telling you, I have 2 phones, and I can tell U it's not easy to find working java application for them. It's not like, "down load this if you have a java phone", it's more like "if you have this phone, download this, if you have that phone, download that, this application doesn't work with those phones bla bla bla. I have to spend to much time trying to find the right download for my phones. How the developers feels... I found an informative blog which sums it up.

Re:Java is not back.

[LarsWestergren]

Notice, 1.2,1.3 and 1.4 only have different libraries and different JVM implementations. That's not what we call language development.

That is absurd... you seem to be arguing that increasing the syntax of a language is the only acceptable improvement. Why is that, adding to the language or adding to the libraries are both just ways to make it easier for programmers to accomplish things.

There are drawbacks to increasing syntax, though you get increased power, the language will take longer time to learn and programs risk being harder to read and harder to maintain, especially for junior programmers.
Also, if you add new symbols to a language you risk breaking old user code. That is why Sun have been very reluctant to add to the syntax of Java; and did not use foreach or for x in y, but rather for (String x: Collection y). People might have variables called foreach, but there is no variable called : anywhere.

You are correct in that improving the libraries and virtual machines is changing the Java platform rather than the language. However, that is no small feat in my opinion. If they improve the VM so that my program runs faster and becomes more secure without me having to change a line of code, that is an enormous increase in my productivity as a programmer. I take that before an increased syntax any day. I know, I'm lazy, I'm not hardcore, I don't have the hacker mentality, but I happen to think life is too short to be spending more time than necessary in front of a computer.

And J2SE 1.5 is just a frantic attempt to add some sugar into Java language.

Oh, so now increasing the syntax of a language is "just" syntactic sugar suddenly? I am very happy with the new improvements, since they finally get rid of many of the most annoying verbose things in Java that people have been complaining about for a long time. For instance, foreach and generics turns this:

void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}

into this:

void cancelAll(Collection<TimerTask> c) {
for (TimerTask task : c)
task.cancel();
}

Easier to read, and also removes a possible class cast bug since it prevents anyone at compile time from accidentally adding something other than TimerTasks to the collection.

1.5 has also taken the first steps to having one JVM for all java programs like in the MacOS JVM done by Apple. This will decrease loading times and memory footprints (for all programs except the first loaded) greatly. If they succeed in adding it to the platform that is.... ;-)

It went to million servers and clients

[struberg]

and thats not bad.
Consider, that java is not only the language itself, but also the whole environment!

And thats the real big difference to mono. Java may run on any Computer since 92' till 2050, without need to take care of what Microsoft will change in 2 years.

Re:It went to million servers and clients

[dnoyeb]

"And thats the real big difference to mono. Java may run on any Computer since 92' till 2050, without need to take care of what Microsoft will change in 2 years."

Let me correct you slightly. There is always the need to make changes to adapt to what MS does. Its just that with Java that responsibility falls to the JVM writers and not the application writers.

A windows JVM is just another windows c/c++ program. Many people keep forgetting that.

I'll called my platform ".COM"

[Vo0k]

I'd win hands down. .NET
(386 000 000 results)

versus .COM
(1940 000 000 results)

Re:I'll called my platform ".COM"

[Joseph Vigneau]

Good to see COMMAND.COM, MORE.COM, and EDLIN.COM are all live and kicking.

This writer is into amateurish journalism

[nysus]

He bases part of his argument that Java is less popular than .NET by doing a Google fight between "java" and "net"???

Java can be a coffee or an island in the Indonesia. Net is a device to ensnare animals and is a verb as well.

And he cites a blog item from a Sun executive as proof that Java is back? Please. The article is nonsensical.

Re:This writer is into amateurish journalism

[pjt33]

Part of? It's a couple of hours since I RTFA, but I don't recall him having any other argument that Java is less popular than .NET.

In addition to nets as trapping implements, consider the common "sentence"

import java.net.*;

Re:like a turtle

[Donoho]

got bored watching

Microsoft is a master at switching enough labels to "keep things interesting". New bells and whistles to hold your attention. (I'm a sucker for a pretty interface) Kind of makes it seem like Java isn't moving at all. Java never left and it's not going to "die". It is a young language that has survived and grown on its own merits and not through billions in marketing hype and R&D and despite it's creaters over protectiveness. It's just getting started.

Either the tool you're using allows you to get the job done or it doesn't. Either the tool improves over time to make your job easier or it doesn't. If you want to see Java thrive, use it.

why bother arguing

[thebdj]

This is another one of those horrible things that happens every once in a while on slashdot. This argument is about as big as MS v. Linux or AMD v. Intel or ATI v. nVidia (for those who care).

The fact is you have some people who are super java fan boys and will stand by it until the day they die and most of them probably haven't programmed enough in other languages to say anything but the few bad experiences they did have.

Don't think I am letting the C/C++ programmers off either. I am one of them and I will be the first to admit I have hardly ever used java, but I have also had enough first-hand bad experience to not want to use it.

The fact is that people will stick with they know best and odds are whichever you learned first (java or c++) that will more than likely be the one you spend the majority of your time working with. So half the people can continue to rip on java now and the rest of you can praise it. I do digital design so I don't care enough about code to get into this argument.

--
"The same thing we do every night Pinky; Try to take over the world!"

Re:why bother arguing

[gov_coder]

I concur. I think if folks actually try some of the newer java apps out there they'll be surprised how light and fast they can be.

One of my favs is Quarbon - which runs great on linux, BTW. This app allows you to make a flash presentation out of your screenshots and mouse clicks. In action using it resembles powerpoint - but its too cool for words!

Re:why bother arguing

[acceleriter]

And who can forget Azureus, the app that convinced me that cross-platform Java apps don't have to be slow and clunky.

Re:As is the case with most languages..

[CountBrass]

You know, I can't remember the last time I was asked to deliver a product that printed "Hello World" so whether or not the JVM is too heavyweight for such an app' is moot. And even if it was: throw more hardware at it. Hardware is cheap. Maintaining code is expensive and C++ has a much higher maintenance overhead than Java does (pointers, object ownership, misused multiple inheritance - the list goes on).

Difficult to install? Use Advanced Installer for J

[Anonymous Coward]

That little app will generate a setup.exe that will:
1) Look for a JRE on the target machine.
2) Download and install one if necessary.

It will also create a native Java launcher, for quick splash screens, file associations, 32 bit icons, etc.

And best of all - it's a breeze to use.

http://www.advancedinstaller.com

Mobile???

[Akimotos]

I never thought of Java as something worth following, because it was my personal experiece that: - it is slow - files are biiiiiig I mean, running some Java app makes the fan of my Powerbook spinning. Face it, only Photoshop and Imovie do that to me ...

But in Europe Java is really strong in the mobile phone environment. I have this SE 900 and it always draws lots of attention and things that strike me most are remarks of non-technical people, like the 16 (or something) year old girl at some fast food joint: "Does it have Java?" Even my sister (30, knows shit about computers) has it on her wishlist: a Java enabled mobile phone...

The fact alone that it is seen as some 'special' thing ... Sun (or Nokia, or whoever) has done a great job there.

Java vs ".net -site:.net"

[hitchhacker]

Java vs .net (excluding all .net tld's)

65.6 million for "Java"
22.4 million for ".net -site:.net"

.. still unfair though. What about relevant .NET websites w/ .net tld's

-metric

Re:Java vs ".net -site:.net"

[hitchhacker]

Nevermind.
Google ignores the initial period in .NET.

-metric

No Star Wars joke?

[Fr05t]

No Return of the Javi jokes? I am very let down :(

The Reason Java 'appears' slow,

[tonywestonuk]

There is this concept called MVC (or model view controller) That is regarded as the way to develop OO based GUI apps. However, pure MVC is the biggest stumbling block to performance.

The idea is, you have a VIEW (The actual GUI Code), that reads it's data from the MODEL, ( a data structure modelling the data that is viewed, and a CONTROLLER, that the view notifies when something happens, and then the controller updates the Model.

This, though well suited for a Web application, does not work well in a windows type environment. Consider for example an order entry screen consisting of 10 dropdown combo boxes, Buttons to add an order line, Tabs to show different areas of the order, (delivery address, customer credits, etc). Now the data model for this screen will be massive - each combo box's entire list of values will be stored within the single Model. On start-up, first the view will be rendered, then the data contained within the model copied into it. This process takes time, and makes the guy unresponsive and sluggish. In a Web application, this is not a problem , as the data has to get to the browsers some way or another.

With Java Swing, there is an alternative - Encapsulate the individual components with the data it requires to display, and only store within the external Data Model, the actual value that the component is set to. Eg, if you want a combo box with a 100 or so currencies to be selected, store the list of currency information, together with the combo box..... Call it a currencySelector or something. The 'Data Model' is still there to contain the actual chosen currency, just not everything else!

This way, you can cache up these components, so when added to the screen, no time is wasted moving all this data from the data model into the component. The data model becomes much smaller, and the components become fully re-useable.

The Swing applications I have written use this technique, and are easily as responsive as a native Windows Application....

Untill industry realises that MVC is not all its cracked up to be, we will be stuck with slow gui's.

As a Side note, Mac OSX uses MVC throughout , maybe this is why Aqua is view to be so slow.

Re:The Reason Java 'appears' slow,

[argent]

Java's got a lot of problems in the standard class libraries and type model. When I started working on it I found the lack of dynamic types and the inconsistent classes are a big problem: I wanted to write wrapper classes around everything just so I could get the bookkeeping out of my hair. Apple's Objective C class libraries (Cocoa) have the same problem to a certain extent, even with dynamic types to help.

I'm not sure that MVC is the problem, though. It's been widely used in a variety of systems since the late '70s on processors that aren't even pocket-calculator quality today. The Smalltalk I played with in 1982 was running on a Dorado that must have managed all of a million instructions per second, and my NextStation (however that's supposed to be capitalised) has a very responsive GUI on a 68030... it actually feels faster than OS X on a G3/400. Java's implementation of MVC may be particularly bad, but the inherent overhead in the design can't be that great if machines as anemic as these can manage it well.

I would put the responsibility for Aqua's performance squarely on the shoulders of Quartz. Quartz is a high quality rendering engine, but to get decent performance out of it you need a good video subsystem and enormous amounts of memory to copy and composite the high resolution pre-rendered bitmaps... not to mention enough processor time to do print-quality rendering in the first place. I expect that Microsoft's next generation video subsystem will be equally aggressive.

Re:The Reason Java 'appears' slow,

[am 2k]

The thing you're explaining has nothing to do with MVC, I'd call it "on-demand fetching".

As a Side note, Mac OSX uses MVC throughout , maybe this is why Aqua is view to be so slow.

Cocoa on Mac OS X uses on-demand fetching for tables and optionally popup buttons (and optionally menus since 10.3).

Re:The Reason Java 'appears' slow,

[nikster]

can you elaborate on that? i don't quite understand... where exactly do you save time over MVC? where does the MVC paradigm say you need to copy anything? Example: the java TableModel. it's an interface, so my model can implement this interface and JTable will access the values directly, without doing any copying.

i have written many MVC apps in Java, and they are performing quite well. The performance improvements i make usually start and end with one single thing: Remove unneccessary updates. Most Java programmers don't realize, but their screens get updated 10 times from all kinds of different updating mechanisms. E.g. user clicks button, update event is fired, sometimes two, a chain of update events from all sorts of components that change as a result triggers a chain of repaint events. Now, if you hold off with updating until all update events have settled down, you paint 10 (and i have seen up to 100 times) less.
Result: what was sluggish is all of a sudden blazingly fast. Even though you "wait" for the event queue to clear.

This is something that one would expect Java to do internally, esp. if you are familiar with the way updating works, but in reality, it's the bottleneck.

The reason i usually adhere to MVC is that it allows you to have multiple views on one model and to easily add more views to one model.

Re:The Reason Java 'appears' slow,

[mpcooke3]

Urm why would you "copy" all the data from the model to the view when using MVC? Yes, that would be inefficient but that's not a requirement of MVC, infact I wouldn't recommend it at all.

The view is responsible for mapping graphics onto a device, to achieve this you don't need to copy any data from the model to the view, you can just access the model data directly whenever you recieve a change notification in the view.

And you certainly don't need to start storing model data in the view to achieve reasonable performance - that would be very poor data encapsulation.

If you want still better performance then eliminate unneccessary notification events or send different notification events for different types of model change. (non-pure mvc but easily support with observer/observable)

Sheesh, I can't believe this got modded so high. I reckon most of slashdot are sysadmins and not developers. (ducks)

Re:The Reason Java 'appears' slow,

[ragnar]

I'm calling BS on this explanation. Unless your model and view are communicated via SOAP or the proverbial horse and carriage, there is little reason for in-process communication to be a bottle neck for applications.

In my experience, the slowness of an application can usually be narrowed down to a few hot spots where the wrong data structure is in use, or database access is done poorly. None of this relates to MVC.

Re:Java is NOT slow

[Dewin Cymraeg]

Horses for courses.

Three things have changed: broadband has meant that applets are not as slow to load as they used to be; machines have got faster; and JVMs have got better (including plugins).

In the project I'm working on (I'm a Java developer, mostly servlet/JSP/struts) we're deploying an applet to provide a richer user experience which HTML alone would not provide. I would not have dreamt of providing this solution even a year ago.

The applet is very usable, only takes a second to load the first time it's used (and thereafter is cached) and the user has a better experience of our product. We're telling our customers to use JRE 1.4.2.

The trick is to use applets when they are appropriate. This is, after all, true of all technologies.

I believe that eclipse http://www.eclipse.org/ and netbeans http://www.netbeans.org/ have both made a huge contribution to showing how Java applications can be used for serious development projects. There is now a huge amount of support for the Java development community, with lots of free libraries (Apache Foundation rocks http://www.apache.org/!) and some great stuff coming out of Sun (Java Server Faces).

Put it all together and you have a very rich environment for creating serious multi-tier applications using web or application front-ends.

For me, the icing on the cake would be the development of a forms standard which allows application-like front ends with a web architecture. Maybe XForms? XUL? This is what our customers want. Combine it with a strict and workable MVC architecture and it'd be my perfect development environment!

Java.equals("chaos")

[bstarrfield]

Well, Java may be back for the time being, but I'm concerned that the language may still crash despite its new found momentum. The Java toolkits are fragmenting, Sun's market position is questionable, and alternative technologies are gaining in both strength and promise.

Sun's marketing materials always mentions Java's strength in enterprise development. But what, precisely, is Enterprise Java? Is it J2EE? Quite possibly, as a theoretical specification. But in real life, the platform is fragmented. On app servers, is Java WebSphere, WebLogic, JBoss, or Tomcat? For persistance: EJB 2, Hibernate, JDO or Cayenne? For Web apps: JSP, Struts, JSF, Tapestry? And just for fun, lets throw in XDoclet, Velocity, Cocoon, AspectJ, and about another thousand or so projects.

The diversity of new Java technologies is both great and terrible: great in the sense that new ideas are being explored that Sun may find to radical to consider putting in their specs, but terrible in the sense that few, if any, Java programmers will have knowledge of the various different projects. This is a real problem, folks. Someone who knows .Net can reasonably be expected to understand most of the C# related APIs. Its unreasonable to expect even a seasoned Java developer to understand how to program the full spread of Java APIs. Someone with Sun certification, an EJB whiz, may be damn well baffled by Hibernate (I've seen this), and may not comprehend why you'd use Tapestry instead of good old JSP.

I think the Java development platform is fragmenting. Sun's work, impressive as it is, often seems to be more concerned with being architecturally perfect at the expense of real world application speed and developer productivity (code astronauts). The Open Source projects seem to be trying to be as cool as possible, at the expense of API consistency and, just like Sun, developer productivity.

The general chaos in the Java world has, thankfully, allowed my development team to finally look at entirely different languages: Ruby, Python, even back to Smalltalk and Lisp. We've chosen this route out of frustration with both the limitations of the Java language and the increasing fragmentation of the toolsets.

As an aside, its fun to watch how hard various Open Source projects are working to emulate a ten year old toolkit: WebObjects. Yeah, WebObjects rules. Object Relational Mapping that works (and Hibernate folks, doesn't require learning yet another XML dialect to get things working). OO web page design, true components (Tapestry is essentially a copy of Web Objects Framework, made more obtuse). I wish Sun had started it's development efforts copying NeXT instead of Microsoft. We'd have a better development world today.

Monkey

[Graymalkin]

I find it amusing that Java is dying because it hasn't totally supplanted Win32 as a desktop application environment. More and more I'm seeing companies replacing their aging in-house applications with Java web services. Where several years ago an internal application might be a VB5 front-end to an Access database today is likely a full fledged web service running on a central server. Such applications are available over a VPN, dial-in modems, or even bridged networks with little trouble. The data is also centralized meaning there's no synch issues within the office. When Mary updates a record Sam gets that information immediately. These applications are also client agnostic so they'll run on just about anything with a web browser.

Centralized web services are capturing the hearts and minds of a lot of companies anymore. Clients for such services can be thin or fat and can run whatever OS is practical. An office full of iMacs can access a web service just as well as an office full of HPs running Linux. If Java is ditched down the road for Perl or Python the database server isn't going to go tits up.

Java's death never really happened, it's just that its success came from an area no one really expected early on. Perl's met with similar success. What started off as a language to parse server logs and turn huge data files into meaningful information became the premiere CGI language on the web. While a successful word processor might never be written in Java, the language and environment are far from dead.

the J2EE market has been going strong for a while

[sethg]

...unfortunately.

When I was unemployed, I had monster.com and dice.com send me a daily email with every new job posting that contained "Perl" or "Java". For those ten months, I saw virtually no Perl jobs, and almost every Java-related job required J2EE experience.

So I took a basic class in J2EE, and said to myself, "No wonder there are so many openings for J2EE programmers: it takes a team of five J2EE programmers a month to put together what a good Perl hacker can make in a week." The hoops you have to jump through to get things to work in J2EE--most of which seem to involve working around Java's static typing and its object model--are absurd.

I've been re-employed for almost a year, thank God, and the group I work with is writing a J2EE-based ERP application. I have seen nothing so far to refute my original impression of J2EE.

But it still beats being unemployed.

Googlefight is a bit hmm

[kahei]

The article notes that a googlefight gives 66 million hits for java and 386 million for .NET (actually, those are the numbers I got just now, but they're similar).

Thing is, the .NET hits include EVERYTHING IN THE WORLD THAT HAS A DOMAIN ENDING IN .NET, which makes it A BIT SILLY.

The article is trying to make out like Java 'went away', just so it can build momentum for a comeback. I don't care for Java as a technology, but I'm pretty sure it never 'went away' at all -- and the fact that Java developers are cheap and common compared to almost every other kind is going to keep Java on the servers for a long long time.

I wish Mono would hurry up.

Odd comment about realtime, C, and Java...

[argent]

"it's actually kind of amazing how ill-understood some of the timing is in C--things like malloc and free can actually be awful" -- Gosling on realtime

If you're doing hard realtime you don't call malloc and free: you use a buffer pool that's sized for the objects you're working on, and allocate objects from that. Not only do malloc and free make a hash of timing dependencies, they make a hash of memory itself. The fragmentation you get from malloc and free are fine for short-running programs or programs that can afford a small slow memory leak as locked-down allocations make chunks of the heap unusable, but for realtime that just doesn't cut it.

It's much the same as in the OS kernel or in file systems, you have pools of fixed size objects that you stick fixed size chunks of data into, your buffer cache and cylinder groups and clists and things. You can use some of the same tools to improve the behaviour of malloc and free, too, but you get a lot more memory overhead because you rarely have the kind of good sizing information that more or less automatically falls out in the process of designing your memory strategy without it.

Bringing up malloc and free as reasons why Java's not so bad for realtime is really a red herring. I don't know if Gosling's just not used to a hard realtime environment, or what, but he's definitely muddying the waters here.

Re:Stop moaning sweetheart

[Undertaker43017]

"And you JAVA peopel should get it into your head that applications need to fit in with the environment they are runnign on. Why the hell should that oen application look out of place?"

I agree completely with this statement. This has become a much bigger frustration for me since I moved to OS X. I used to use NetBeans for developement. Netbeans looks fine on X11 and Linux, and OK on Windows, but looks horrible on OS X. So I switched to Eclipse, and it looks great. The Eclipse folks have shown that a little effort can make a Java GUI look good, and be integrated well into the native environment.

GC should handle circular references

[brlewis]

When did the Java garbage collector ever fail to deal with circular references? Real GCs don't work by reference counts.

Re:GC should handle circular references

[DarkMan]

It handles them fine.

The problem is that if you've got a circular loop of, say, 15 objects, and a reference to a single object. The GC can't get rid of the fourteen other objects (or whatever part of them are actually redundant) because there exist references to them all. If that ciruclar reference were not present, then the GC can destruct all the objects without direct references.

Note that a manually managed memory model wouldn't nessecerily help in that situation - if you free() the objects you no longer need, not noticing that there is a cirular reference, you can end up with a particularly painful to sort out segmentation fault if you later acess that ciruclar reference (probably in a call to free() itself).

Java doesn't exist!

[dfj225]

Well, according to my research Java doesn't even exist! There are absolutely no servers existing in the .java domain. However, there are many, many servers with .net. Apparently, Java has much catching up to do if they ever want to pass Microsoft.

Pot, Kettle

[mihalis]

In the first article, Eric Allman says I'm curious about a couple of other languages. My favorite language to hate is Perl. It seems like no real thought was given to the language. It kind of grew over the years. So it's just really deeply, deeply ugly.

And this is from the guy who wrote Sendmail !

Re:Stop moaning sweetheart

[Undertaker43017]

I agree, but the project that this thread is about is a consumer targeted product, so perhaps some effort should be put into making it more "native feeling". In Java that isn't too hard to do.

The whole native OS interface thing, isn't a Java only problem. Open source native apps suffer the same problem, for instance OpenOffice doesn't take advantage of Carbon, and looks and works poorer on OS X. Unfortunately with native apps, this is a much harder problem.

It all comes down to a resource problem, if all OOS project's had the resources that Eclipse does, they could produce a native look and feel app for all the platforms they support too.

"If you are doing development for OS X, just use Objective-C... that is more fun anyway."

I'm not doing development for OS X, our target is any platform that has a Java VM. I just happen to develop on OS X, the rest of the team develops on *nix, and Win32.

Why is java better than perl/python....it's NOT.

[Lodragandraoidh]

"Were I a CIO facing these issues [the technical effort needed to port an app off one app server to another], I'd stay focused on the one thing definitively under my control - keeping the cost of substitution, of at least application portability, as close to zero as possible. How? You guessed it, I'd write to Java." - Jonathan Schwartz Sun COO

Ummm - what about python or perl? Both of these are just as portable - requiring zero modification of the code to port to any OS.

And don't pull out the 'java is more efficient' bull scatology. I have a java application right now that my team is rewriting in perl because it runs too slow (and also has a memory leak - code is vendor proprietary, so they won't let us see/modify the source to fix it). There is nothing I can do with java that I can't do with perl or python - as much as David Berlind would say otherwise (his statement in the article suggests perl and python are good for 'scripting', but not robust enough for large applications). As a supposedly impartial journalist/editor for ZDnet - I have to question his motives for jumping on this bandwagon. Also, his primary focus on writing, rather than building apps, hardly makes him qualified to make such an accessment, imo.

Given that I would have to disagree with this editorial in JDJ.

The words of the COO of SUN, who has a vested interest in the success of java, and the words of a journalist, who from all appearances doesn't have the technical background to be taken seriously concerning application development issues, in an editorial on a website dedicated to java development, hardly seems like 'news' more than a marketing ploy.

Java isn't going anywhere but up

[bokmann]

Java isn't going anywhere. Java has at least reached the status of 'the next cobol', to quote Stu Halloway. This isn't a comment on Java's speed, quality, and such, it simply means that even if all Java development stopped today (which it won't), there has been enough investment in Java'based intfrastructure that the maintenance alone will be quite a large job market for years to come.

Java is NOT dead/dying. New, important projects start with it every day. I am the president of the Northern Virginia Java Users Group, and we have a steadily growing membership (now over 1100 members). I am also a speaker for the No Fluff Just Stuff Software Symposiums, and the discussions about Java tools, techniques, etc dominate that conference. Why? Because it sells. .NET has been gaining some momentum, and c# is undoubtedly the 'next big thing', but Java is here to stay. If you are a software engineer, Java is a 'safe place' to be for new and interesting work for the next 4+ years, at least. (That doesn't mean software engineers don't need to have diverse talent - but that is a topic for another rant).

We're comparing apples to oranges here

[JustAnotherReader]

Everyone's talking about how Java requires the user to install a JRE and how Java is slow (I beg to differ) and how Java Swing is to bloated. All these complaints assume that Java's predominant use is to write desktop applications.

But that's not what Java is being used for. The most common usage of Java is for high volume dynamic web sites such as Amazon.com and most online banking systems. The combination of Java servlets, Java Server Pages and Java based web engines (WebSphere or Web Logic for example, or even Apache and Tomcat) are becoming the most common usage of Java.

I work at a major California bank and have worked on various web based applications for about 9 years. Java is the standard for writing those types of dynamic web apps. For example. When you want to see your financial summary you wouldn't expect that there is somebody writing a web page just for you every time to make an ATM transaction would you? Of course not. You log in and we identify you. Then we go to an Oracle database or a bank host system and get your transaction history. We load that into a data object and pass it to a JSP which dynamically creates the web page with your transaction history. Java excels at that kind of application. And by the way, I can develop my code in Windows 2000, move it to a Linux box to do some basic testing, and then move it (all without recompiling) to an IBM AIX Unix box and have everything work the same on all these different environments. That makes my job easier.

So we need to stop comparing apples to oranges and saying things that essentially sum up to "A badly written Java program is slower than a well written C program" or "Java was slow 6 years ago so it's still slow today" or "I don't agree with the language designer's choice of [properties, no operator overloading or whatever language peeve you have]". Look at how the language is actually being used and you'll see that Java is indeed alive and well.

Re:Embedded Java debunked

[shadow_slicer]

Did you even bother reading what the poster wrote?

He's not talking about using Java on PPC, ARM, or AD Blackfin. He's talking about using it on machines designed for Java.
In these cases, most of the 'JVM' is implemented in hardware, so it's not slow. The included classes are scaled down to what you could conceivably use (none of the GUI stuff), so it's not really that bloated.
The GC is still non-deterministic so you wouldn't want to use it in an avionics system, but it would work fine in embedded systems without hard realtime constraints. And since most embedded systems don't have hard realtime constraints they would work fine in most embedded systems.

That being said, I wouldn't want to use one....(eee...Java....).

I don't use Java

[CaptainTux]

I've been programming professionally since I was around 15 and have a CompSci degree under my belt along with probably a few million lines of code. I know what it takes to develop a large scale application and I'm definately willing to put in the work to learn a new language. I've learned solid principles of OOP and undertand where Java is coming from and trying to accomplish. I even took the time to learn it a few years back just to have it under my belt.

Java is a good language. Yes, there are issues, but they could be resolved by Sun fairly easily. But, in most cases, Java simply isn't needed. Statistics show that the vast majority of software applications being developed are not "mass market" type apps but rather stuff that is used in house. Most shops have standardized around one platform or another so cross platform isn't really an issue. And, when it is, it's usually trivial to edit C code and recompile for the new arch.

Lastly, let me tell you a little story: I am currently launching a new startup aimed at developing a kiosk for the entertainment industry. Originally, everyone said I simply *had* to write my software in Java because of an infinate number of reasons. Even as an experienced programmer, I was dumb enough to buy into it and try. Within a few weeks the software had become so slow and bloated that I knew I had to find something else. Where do you think I went?

Python with the WX extensions.

Python offers me everything Java can (WORA, Speed, Good GUI enviroment, etc) and is absolutley painless to learn. In fact, I am LEARNING the language AS I write the new software and it's not slowing me up at all. There are times I have to go back and fix things but usually it's pretty straightforward. Python is, to me at least, a Java killer.

I think that Java has some strong points. But, ultimately, it's no stronger that some other languages out ther (think C++, Python) and in some ways weaker. Sun needs to do something to get Java back on track. They can save the language but they need to drop the arrogance and get back down to basics.

Re: If only wxWidgets were truely x-platform

[Rob Y.]

wxWidgets is a really nice toolkit. The problem is that it isn't truely cross platform where it counts.

Like it or not, the 2nd platform most business app developers want to target is the Macintosh. I tried porting a Win32 app to wxWidgets a while back, and it looked like I could get it to work on Windows (and probably Linux), but the Mac port was just not there. Widgets didn't draw, size or behave right, and I had problems getting sockets to work right.

It appears like there's a push on currently to get the mac support up to par (at least their website is soliciting contributions). It's a shame that Apple wouldn't fund this themselves, but I guess they're still pushing native Mac toolkits (though why, at this point in the game, I can't imagine).

Re:like a turtle

[Com2Kid]

• It might have left, but if you've ever watched a turtle you know they can wander off without you noticing because you got bored watching said turtle try to run.

Some turtles are oddly enough, fast as heck.

Even box turtles can go really fast when they want to. (Oh crud, where did the little bugger go? Ahh!!!)

I think it'd be nice if Sun did some sort of multi-platform automatic binary distrobution system instead of that darn VM, Java itself is a nice language, the API is simple to use for many many things, the only issue is the darn VM!

If compiled binaries were more common, or even some sort of limited compiled binaries, compiled to the LOWEST level possible and still be run in a sandbox, I think Java would have a better chance.

I mean heck, how many plateforms are there REALLY browsing the Internet? Three: Windows, Macintosh, Linux.

For most applets, multibinary support would not add THAT much more size to the applet, since most of the size of an applet is likely to be in the graphics and sound department anyways.

Oh yah, talking about graphics and sound:

Sun: STOP IT WITH THE MINIMAL LEVEL OF SUPPORT CRUD!

2.4Ghz machine;

800x600 resolution;

Instanciating a new Color object to draw random lines: 100% of my CPU use.

Head --> Wall

*POUND* *POUND* *POUND* *POUND*

stupidstupidstupidstupid.

This is not even counting how slow doing other graphical operations is, ugh! Please, sun, optimize Swing on a per machine basis!! On Windows it should automatically take advantage of DirectX, on OSX, Quartz, on Linux, umm, whatever Linux uses (MESA? Err, no clue).

Annnnyways. Aside from the, umm, performance issues (which ARE a killer), and the graphical issues, oh, yes, wait, one more mini-rant on graphics and Java.

People complain that making a GUI in Java is a pain, indeed, it IS a pain, but you know, compared to other APIs, it is not ALL that bad. Just a bit odd at times, having to work with a lowest common denominator toolkit. Actually it is NOT truely crossplateform, as the dude with the Mac OSX Laptop in my class wrote GUIs that didn't "look right" on Windows and the rest of the class on Windows wrote GUIs that didn't look right on his box. ^_^ Oh well, they were USEABLE more or less, only a bit of overlap between elements, hehe.

Yah, umm, that was good for a couple of laughs.

Oh yah, the language.

Fun to program in, very interesting, makes me WANT to program, easy to use.

Just performance bites. Horribly.