Slashdot Log In
The "Return" of Java Discussed
Posted by
CowboyNeal
on Fri Aug 13, 2004 04:20 AM
from the off-again-on-again-languages dept.
from the off-again-on-again-languages dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
There has been some good alternatives (Score:3, Insightful)
Mono
Cocoa# and Gtk# (recentely kn
Java is slow, obeist, and heavy.
Re:There has been some good alternatives (Score:5, Insightful)
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.
Parent
And for anybody who doesn't believe... (Score:3, Interesting)
And anybody who doesn't believe this might want to take a look at why kast wasn't written in Java [sourceforge.net]. 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... (Score:3, Informative)
If only everyone knows how to write Java properly....
Re:And for anybody who doesn't believe... (Score:5, Insightful)
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.
Parent
Re:And for anybody who doesn't believe... (Score:5, Interesting)
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.
Parent
Re:And for anybody who doesn't believe... (Score:5, Insightful)
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.
Parent
Re:And for anybody who doesn't believe... (Score:4, Informative)
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#.
Parent
Re:And for anybody who doesn't believe... (Score:4, Informative)
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.
Parent
Re:And for anybody who doesn't believe... (Score:4, Insightful)
``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.
Parent
Re:And for anybody who doesn't believe... (Score:5, Interesting)
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
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
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
Parent
Re:And for anybody who doesn't believe... (Score:5, Informative)
One doesn't have to look far to find claims there that are simply wrong. For instance:
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. ;-)
Parent
Re:There has been some good alternatives (Score:3, Interesting)
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 (Score:4, Insightful)
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?
Parent
Re:There has been some good alternatives (Score:5, Insightful)
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
Parent
Return of Java (Score:5, Insightful)
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 ...
Re:Return of Java (Score:5, Insightful)
- 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.Parent
Re:Return of Java (Score:3, Insightful)
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 (Score:4, Insightful)
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...)
Parent
Re:Return of Java (Score:4, Insightful)
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.
Parent
Re:Return of Java (Score:5, Insightful)
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...
Parent
Keyword being: Enterprise (Score:3, Insightful)
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 init
Re:Keyword being: Enterprise (Score:4, Insightful)
Run Eclipse sometime.
Parent
Re:Keyword being: Enterprise (Score:4, Insightful)
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.
Parent
Re:Return of Java (Score:5, Informative)
The SUN's java implementation is non-free but there are other free implementations of the java standard, look at http://www.kaffe.org/ [kaffe.org] for one.
Parent
Request for interview (Score:5, Insightful)
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. (Score:4, Interesting)
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 [ibutton.com] - 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 (Score:5, Interesting)
Java now has an astounding array of libraries to use these days. Look at for some good ones [java-source.net].
Stupid comparison (Score:5, Informative)
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.. (Score:5, Insightful)
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:As is the case with most languages.. (Score:4, Insightful)
Parent
Source critique (Score:5, Insightful)
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? (Score:5, Funny)
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 [slashdot.org], 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 [slashdot.org] two weeks back), there is news on Solaris ("Linux apps on Solaris" [slashdot.org], "Solaris coming to Power architecture" [slashdot.org]), there have been bits about their cool Sun Rays on Linux [slashdot.org], their R&D with the chips without connectors [slashdot.org], and rumours that they could buy a key player, Novell [slashdot.org]. There's also Looking Glass [slashdot.org].
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. (Score:3, Interesting)
Java 1.5 goes a long way to help that, what with iterators, autoboxing and such.
I'll called my platform ".COM" (Score:5, Interesting)
(386 000 000 results)
versus
(1940 000 000 results)
This writer is into amateurish journalism (Score:5, Insightful)
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.
Mobile??? (Score:4, Interesting)
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
Monkey (Score:5, Insightful)
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 (Score:5, Interesting)
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 (Score:5, Informative)
The article notes that a googlefight gives 66 million hits for java and 386 million for
Thing is, the
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.
Java doesn't exist! (Score:4, Funny)
Pot, Kettle (Score:5, Funny)
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 !
We're comparing apples to oranges here (Score:5, Insightful)
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.
It went to million servers and clients (Score:4, Insightful)
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.
Parent
Re:It went to million servers and clients (Score:5, Interesting)
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.
Parent
Re:Java is not back. (Score:5, Informative)
Oh, what BS. Like that is the only thing that has changed
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 [sun.com], 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.
Parent
Re:Java is not back. (Score:5, Interesting)
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.
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).
Parent
Re:The Reason Java 'appears' slow, (Score:4, Insightful)
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.
Parent
Re:The Reason Java 'appears' slow, (Score:5, Informative)
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.
Parent
Re:The Reason Java 'appears' slow, (Score:5, Informative)
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.
Parent