Slashdot Mirror
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?"
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:
Discuss ...
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.
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.
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.
Bad analogies are like waxing a monkey with a rainbow.
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).
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
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?
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.
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.
---Technology will liberate us if it doesn't enslave us first.
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.
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.
Please correct me if I got my facts wrong.
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++.
.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.
.NET has borrowed so many classes from Java so they should call it J--.
So, please dont come with those crap arguments, because they are not true.
But what is true; c++ will always be faster than java,
What must be really annoying, is that
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.
I'm a loner Dottie, a Rebel.
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.
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.