Slashdot Mirror
Java Rocks On Linux
Begonia writes "While we're on the subject of Java, I'm really impressed with its performance on Linux these days. I'm using IBM's latest (1.3) version of the JDK,
which has only been out for a couple of months. And I just stumbled across this latest set of benchmarks for various JDK's on Linux and
Windows here. Not dated, but must be at most a couple of weeks old. Lots
of very interesting food for thought."
The facts have come down to this. Java applets (Java on the web) are going to be slow by their nature. The use of a Java plugin helps this some. The Novell GUI components are written and ran using a 1.1.7b compliant virtual machine. This version is slow. I will not argue that, but move this to a newer virtual machine with a Just-in-time compiler or HotSpot the speed difference will be seen. The problems so far with Java is that in its early days it was slow, and many vendors have not updated there products to use a new JVM. I have been using Java since it came out and have seen many of the new Java applications that are starting to be used more in mainstream situations, and the speed is now quite up too most native apps (not as fast but very close);
you really should do! LOL
Together, we are strong; Apart, we are stronger.
Hm... all I know is that a month ago I programmed for a couple of weeks using Netbeans on linux. Then on the last day I transfered it to win2000 on the same (triple boot) machine.
Netbeans - which is itself written in Java - started up almost in HALF time on Windows 2000 than on linux. And yes, my kernel WAS optimized for K7 (Duron) and it was latest test5 or whatever, plus the latest either Sun or Blackdown JDK. Blackdown has built-in JIT and native threads. I haven't tried IBM's, I forgot about it.
The program was a multithreaded simulation (not a commercial quality code, it wasn't optimized or anything) and was able to run (I think) with more threads on win2k before choking. Still, it was disturbing since I was expecting clean sweep by linux.
Ah, ick. You will be *much, much happier* if you run-don't-walk to 1.3.0. I know that early JDBC had a lot of problems like you describe.
And GC in Java is definitely not suitable for attempting to prevent non-memory resource leaks.. even the finalizer mechanism won't do it, since it is not strictly analagous to the C++ destructor mechanism. If you need to prevent resource loss, you need to wrap your activities with a try bracket and use finally to clean up.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Actually some VMs (I think was IBMs 118 VM) do cause many additional entries in the proc table. It confused the heck out of me the first time I saw it until I realized that each thread showed the memory use for the entire process. In my case it was an app that had about 60 threads each with 25MB use which multiplied out is significantly more RAM+swap than I had. Off topic, but why is it that each of the threads maps to a separate entry in the proc table?
The "view page info" tells you when the page was last modified. Not when the benchmarking was done. Big difference there.
I develop Java under linux, but I still keep a windows box on my desktop for running and debugging java applications. Sure, linux jvm's are improving, but as Michael Hirsch demonstrated in the August 2000 Linux Journal, Microsoft and Symantec's JVM's for windows run faster than even natively compiled Java code under linux(using gnu gcj). So of course the windows JVM's run astronomically faster than linux JVM's.
The windows machine I use is old and slow, and doesn't have much ram. The linux box is a new, high end, smp box. The windows box blows it away when it comes to Java performance.
Like using stringbuffers instead of strings when doing lots of concatenation.
There are too many articles about java popping up on slashdot lately. It's ONE programming language, and it's starting to give us all caffeine poisonning. :-P
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
to use a StringBuffer, but they won't do it for code within loops, like
which allocates a new String object for each iteration, creates a StringBuffer for the addition, and converts that StringBuffer into a String -- leaving you with two objects that need to be created, only to be immediately garbage collected for each iteration.
I posted some tips for optimizing Java in another thread -- many of the other replies in that thread are good as well. Have fun.
~wog
Why do people only mention speed when evaluating Java? Memory footprint should enter the discussion too. And unfortunately, Java on Linux seems to suffer from bloatitis.
A Swing app I am developing under JDK 1.2.2 for Linux uses about 20MB of RAM without JIT. It's not really that big a program. When I tested it under IBM's JDK 1.3 (prerelease), it ate about 30MB of RAM. With Sun's JDK 1.3 with Hotspot, it still uses about 20MB of RAM. Sun's JDK 1.3 tries to reduce memory footprint, but I am guessing that the additional overhead of Hotspot and native threading tends to erase this gain. It does start faster though.
When writing a Java GUI app, speed may no longer be relevant. Most of the time, the application is waiting on user input. My app runs just fine on a P166 on a JVM in interpreted mode only (no JIT). Any speed advantage in the JVM is not noticeable. But the memory footprint is noticeable, and this also translates to a long startup time.
Quake 3 has NO java in it. Carmack was quoted as having thought about using java. However, he has used his own interpreted language. Note the Q in QVM is different than the J in JVM...
Speaking of bad raps, it's quite easy to get one simply by saying you code in VB. There are many bad VB programmers out there, but that's becuase of the sheer volume of VB programmers out there. VB and its notorious cousin, VBScript, are the Perl of the M$ world; given Windoze's market share, it's no surprise that there's a large number of VB programmers out there, and naturally you'll have a large number of bad ones. You'll also find many good ones.
However, bad VB programmers make a subset of the many bad programmers doing bad work in every language. One of the benefits of open source software is that I've had a chance to see how many bad C, C++ and Perl programmers are out there. Especially Perl. If you think that VB programmers are a piss-poor lot, then go look at some open source Perl code on Freshmeat or SourceForge some time -- you'll swear these people rode the short bus to school. You'll see brittle code, coupling on an near molecular level, barely cohesive modules, and a style that would make you think they were going for job security through code obscurity. For an excellent start, look at some early versions of Slashdot's source }:)
VB's object model is actually decent. It feeds off Java's, and with version 7 (if the announcements surrounding VS7 are to be believed), the object models will be kissing cousins. VB7 will have inheritance (finally), constructors, variable declaration/initialization on the same line and method overloading. VB in its current state has property procedures, which are syntactically sweeter that creating get/set methods in Java. Some of the best Java programmers I've seem came there from VB, and some of the worst have come from C++ (particularly those who just used it as a souped-up C).
As for IDEs, I think auto-complete (or Intellisense) is the programmer's greatest blessing, especially when developing in languages with large class libraries. As for drawing the user interface rather than hand-coding it, I say great! Anything that allows me to hand over UI design to a proper interface designer who cares about human factors over coder cred is fine by me. I think IDE developers should concentrate on making the GUI code that their IDEs generate better -- Borland have proven it's possible with Delphi and C++Builder.
Correction: Publicly owned companies have to operate in the best interests of key shareholders. More than once I've seen companies act in the interest of major minority shareholders and against the interests of others.
--
My name is Sue,
How do you do?
Now you gonna die!
I have solid evidence that Java is slow and cumbersome: The IBM Point Of Service system. I work at parts counter at CompUSA, where these units are used as cash registers. These registers are running NT4SP5 (strange, considering that there are USB ports on the units). The POS program used is entirely written in Java. On power-up, there is a scripted FTP session to download JPEG files used for instant advertisement. The monitor functions as a display of the receipt (to comply with a recent town ordinance to show the customer the receipt; I'm going to oppose this ordinance, since it only spawns more Java programmers). The keyboard latency (time you have to wait before pressing another key) is 150ms. If the enter key is pressed before this time has elapsed, a certain letter will appear (proving that the Enter key and Escape key are remapped in the program). In C programs, there is no keyboard latency. The thermal receipt printer (suspiciously named the "IBM SureMark") makes a stuttering sound when sent its data to print. During the test print/paper cut sequence, there is no stuttering, proving that the Java program lags when sending data. There also have been problems recently when the entire Java data files were changed; there is an option for what kind of CompUSA credit card payment method (so we can manually trigger the 6 month no interest plan), but sometimes (and this has happened at the damndest times), a credit card will come up with a message of "Use Another Tender," and it won't let the cashier enter in an auth code. This became annoying once because I actually had an auth code from the creditors!
So next time you say that Java is fast, just walk into your local CompUSA, and watch the cashiers cursing at the register terminals. The POS terminal program was coded by IBM's (snicker) Java (snicker snicker!) technicians (ROTFL!!!).
I am majoring in Computer Engineering at the Wentworth Institute of Technology in Boston, so I will have to learn programming. However, I have made a vow to learn C(++) as a second language. Maybe I'll learn Java, but it will have no place for me, since Java-driven drivers are the worst drivers.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
That's all I'm saying. For simple, one-time one-liners, it's probably OK to use "+". However, most performance problems that need optimization arise in loops; most Java performance problems have to so with unnecessary object creation.
~wog
The only one I'll give you is XML support. Java probably has the best support for XML right now - too bad its general text-handling sucks.
I shouldn't add to this Thread from Hell, but I cannot resist...
... translate to C++. :-p Should only take a couple of months...
I am currently working on a 3D game/simulator written in Java, using 1.3 + Hotspot + OpenGL. So far it is performing excellently. I see no garbage collection pauses, no memory thrashing (yet), and get 40-50 FPS without *any* optimization. In fact, the current code base commits several crimes against nature, and uses some incredibly hairly floating-point algorithms. Java chugs right through them.
I am not fond of a lot of Java's *libraries* -- like AWT, Swing, Java3D -- I fault Swing for being too complicated and monolithic, and Java3D for not being OpenGL. Therefore I don't use them. But the language is clean and nice, and now it's fast too. Sure, there is some overhead compared to optimized C++, but I am not competing in the FPS-junkie market.
Some benefits: Supporting the game will be much easier when my users can give me a stack trace + line numbers where the program failed. No need for a separate scripting language. Users can extend w/ their own classes. Patches can be on a class-by-class basis. And so on.
Now don't get me wrong, I'm scared as hell about releasing a Java game and the market accepting it, and trusting Hotspot not to have any show-stopping bugs. But right now, the only way you can tell it's written in Java is the little coffee cup in the upper-left of the window. I think if you don't have to be cognisant of the fact that it's in Java, you won't mind when you find out.
Anyway, my backup plan is
BTW you can read my Tech File on flipcode.com if you want to read about my progress.
Nothing prevents the Java 2D vendor's implementation from using hardware acceleration, and in fact it should indirectly do so already. For example, if the implementation makes calls to DirectDraw, than it should end up using acceleration. Ditto with Quicktime/QuickDraw.
Also, I disagree that the performance sucks.
- ... that you can't do in ASSEMBLER.
- ... that you can't do in PL/I.
- ... that you can't do in LISP.
- ... that you can't do in PILOT.
- ... that you can't do in TURING.
- ... that you can't do in FORTH.
Get over it, bud. People use the tools they like for the jobs they can. Other jobs, where shit like this is forced down their throats by PHB's, they grumble and do the best they can.Personally, I like Delphi. And I can't wait for Kylix to debut. But you don't have to be an asshole about it.
"The only good windmill is a tilted windmill."
I really do not have problem with Transmeta, as I often do the following: gdb disassemble blahblah Guess you do not know much about compilation and stuff like that. C is still much more superior than Java which produces lousy bytecode which then excutes on a VM. Ok, add one more layer maybe get more fun. Create a layer called "JavaZealot AttitudeChecker" to kick all other's butt would be nice.
Together, we are strong; Apart, we are stronger.
I wonder how IBM's new embedded Java VM for Linux compares. It's available as a beta for x86 and PPC Linux. MontaVista recently made an announcement that they'll be distributing it with their release of HardHat Linux.
--- One world, one chance Doc.
Thanks!
:-)
:-}
I don't believe it - actual useful information on Slashdot
I'd love to run to 1.3, but we're using 1.1 in production right now - that means a complete new test cycle.
I guess I'll wait for the next release
I suppose all this affect benchmarks too; most readers today will be more interested in testes that show server-like workloads.
I think if my testes showed server-like workloads they'd rupture.
I would be a paid subscriber if Taco and Hemos weren't such cunts
I make my living that way. Of course I am professional then.
This is why they call it a "virtual machine". The JVM is the "target architecture" for "compiled" Java code. It has its own binary-coded instruction set, and Java "compilers" simply produce output for that instruction set. The JVM takes instructions for its "architecture" and *interprets* them to the native architecture (e.g. Intel/x86, Sun/Sparc, etc). It does not matter that you think you've "compiled" your Java code by typing a command which reads a text file and generates a binary file. The binary file still has to be interpreted by the JVM.
I can only assume that you did not know this, Anonymous Coward. Does this help clue you in?
Dave Bailey
Start considering design issues more and tools/language issues less, if you want to be a good programmer...
Besides, claiming that "Java is slow" is silly anyway, since Java is just a language. Even if it were slow, it would be the JVM -- not the language itself -- at fault. The newer JVMs are nearly as fast as native C/C++, assuming a properly designed application.
And your point is...? IBM's JRE for Linux works quite well, and is actually rather fast. I don't know if it supports OJI or not, but if it does, then it should (in theory) work fine without waiting for Sun to get their shit together and make a Linux release.
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Comment removed based on user account deletion
Perl is the king of text processing languages (no contest)
Any language X is the best at Y thread ought to result in the spontaneous combustion of the poster's terminal. From a technical standpoint, you could make a pretty strong argument that Icon is a much better text processing language (and a better language in general) than Perl, and that Oberon's Juice JVM is structurally better-suited to delivering high-performance platform-independent binaries. Of course, you won't hear much about them -- or dozens of other great technologies -- because developers seize on the first thing they like and congeal and harden around it, forever after ignoring anything else that comes along. The popularity of programming languages and other technologies has next to nothing to do with technical considerations and everything to do with the same instinct that makes 13-year-old girls decide they all like Britney Spears simultaneously. Of course, software engineers can typically provide more compelling-sounding arguments for why they closed their minds as soon as they found Language X.
Maybe this is unavoidable in the relatively conservative, unimaginative corporate world -- the help wanted section in twenty years may still consist of a set of twenty or so acronyms repeated over and over -- but there's no excuse for it in the (let's face it) largely unpaid world of free software. Get out more.
--
Proud member of the Weirdo-American community.
I find it hard to belive that Java is really faster on linux than it is on just about any other platform. At least Java 2 anyway. Do they have native threads yet? Blackdown changed their status page. Where's the checklist page? If they do use native threads I guess they don't use ptreads. If they did each thread would appear as a separeate LWP. Imagine running a Java proggie that had 300 threads and then looking at top and finding 300 6MB processes(linux threads reports same total memory usage of all threads for each individual thread). Although I have never done any benchmarks my feeling through expirience is that its just a little slower due to particular memory usages and other stuff I have heard. But maybe they sorted some of that stuff out. Great to hear if it's true. I wouldn't develop on anything else even if it where half the speed.
KidSock
As someone employed to write enterprise level systems using Java, EJBs, Servlets and JSP I have to agree.
For client-side stuff, if you're deploying on Windows use Delphi or VB. If you're deploying on Windows or elsewhere use a web client, with the right mixture of static html and dynamically generated by JSP/Servlets.
For server-side stuff, Java is very very fast to develop, and in EJB servers it's very very dependable, scalable and fast. Integration with the various legacy systems you have is also very easy, through CORBA/E-Link/etc. Most vendors of enterprise scale systems are providing native java APIs now too.
I use Java at work because for writing server-side business logic, it's the quickest easiest language to use and my business people demand software fast.
~Cederic
You forget that Java can be compiled too. Just look at GCJ
Java is really three things. JWZ has a nice paper about this. It's a language, virtual machine, and class library.
The JVM indeed slows things down, and the class library does some too. But Java the language, even when natively compiled, is slow all by itself.
After all, the GCJ project uses the gcc/g++ compiler code base. So why is a C++ application compiled with g++ so much faster than a gcj compiled application? Must be the use of exceptions and GC (in the form of a shared library with gcj).
So Java isn't slow, exceptions handling and garbage collection are slow.
Most modern Java VM's use incremental, generational GC's that can execute in their own thread. As such, you should not have GUI freezes during a garbage collect. If you are having this problem, check your VM setup.
Swing does not provide a native GUI. If you want this, you should use AWT. Swing is meant to allow you to design your own look and feel (and btw, adding wheel mouse support to a look and feel isn't THAT hard).
Generally speaking, it's safe to say that the standard GUI libraries for Java are not as muture as one would like them to be. However, the language itself is quite well suited to building GUI applications, and really just needs to have the GUI libraries updated a bit more and it'll be pretty sweet.
sigs are a waste of space
Execution speed is only a minor issue when choosing a development language - otherwise, wtf is there so much stuff written in perl/VB/etc.
When someone in marketing comes to me and says 'we have this new campaign, but the system needs to support X in 3 weeks or we can't run it' then I like being able to answer 'we can do that'. The reason that 'we can do that' is that we are using a language that lets us develop quickly, dependably and still write maintainable code. Sure, re-writing something in C could shave milliseconds off the time taken to handle each customer - but even in that one system out of every 20 where those milliseconds matter, it's almost always cheaper and much much quicker to just chuck some slightly beefier hardware at it.
~Cederic
I'm glad to hear that we now have "Java Rocks". Not that I have the slightest clue how to implement an application or class library on this new development, but it just sounds cool.
:-) I have enough serious rambling yet to finish.
Isn't a cool name the core of any new technology product?
It brings up an image - I see it now! A penguin hurling Java Rocks at stained windows...
Enough pointless rambling
A dingo ate my sig...
...when they run out of cute caffeine inspired names to call things. Now let me get back to that new compiler I'm working on. I call it "The Percolator".
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Hmmmm - I did realise you & your ilk were still alive. I had though that in 1998/9 you and the others like you peddling this Redmond line line had all either been beaten to death, choked on your own froth (mouth froth) or just evaporated. Redmond - you know, the ones who invented a basic interpreter that ran on 12Mhz x086 processors but still did the job and survived. Java has you licked and you just don't or won't get it. Pls return to your grave & sleep in peace while we get on with life & the job done (with Java of course). Cheers DSM
And by sticking to platform independent, it is not glued to the operating system tightly enough to use system resources directly. This makes it even slower.
Together, we are strong; Apart, we are stronger.
I like Java, but I tend to like Smalltalk more.. just because I feel Smalltalk's class libraries tend to be more mature and elegant, and the syntax is more "english like" as opposed to "C like".
:eachElement | eachElement doSomething ].
For instance, in ST I can iterate through a collection like so:
myCollection do: [
which in the Java is basically:
Iterator it = myCollection.iterator();
while (it.hasNext()) {
(ElementType) eachElement = (ElementType) eachElement.next();
eachElement.doSomething();
}
I donno, I find the first more understandable even though it has less words.
the ST stuff in square-brackets is basically a block, which is pretty much like an anonymous inner class with one method, "value", that is called upon each element iteration by the do: method.
-Stu
It would certainly help to quickly reject all obviously useless or juvenile posts such as "first post", penis bird ads, etc. I have found in that there is absoutely no relationship between the value of a post and how it is moderated, most of the time. Therefore to read the really good posts, most of which are moderated at level 0 (not obvious flamebait but not "notable" opinions by those who say the expected platitudes) I have to also deal with the crap.
I really don't like the way AC posts start one point lower, at leve 0, than posts from those with user accounts. A user account does not hold the writer responsible if he uses a hotmail or other indirect email address, and the user information furnished is often intentionally misleading. User information should be confidential anyway. If someone wants to publish his email address in the body of the post that should be up to him or her, but otherwise only Slashdot should know the true user info and should guard it carefully. Even AOL does that for its users.
Slashdot is too chickenshit to do the right thing and exercise editorial control by removing crap posts (many of which are generated with trolling robots) and therefore all readers are penalized. Other sites edit posts (delete the really offenseive, useless ones) and don't get sued out of existence. What's the deal here?
I wish to hell that slashdot would die but there is nothing to replace it with. You guys killed kuro5hin. Actually, the choice of stories here is quite good, but the lifetime of stories is far too short for thoughtful posts most of the time. Again, more often than not the best posts are not even visible at the default viewing level, and some of the replies to posts that don't show up are even better.
Fact is, you can't say Java is fast or slow, it depends a lot on the context.
This hole thing is irrelavent, Due to the fact that -even on Linux- Java is slower than goat-ass. Personally, I don't understand why Java has all these fans when Python basically does everything (Except that security feature) and more that Java can do, yet remains about 100-1000 times faster.
"Your pen is bugged..." "How do you know? " "This is an action thriller"
The first problem I see is that the first posts to an article are the most likely to be modded up. Moderators tend to hang around the couple most recently posted stories.
Not everybody refreshes Slashdot every two hours. The people that do, are the ones that agree most with the stereotypical slashdot agenda.
Insightful posts take time. It could easily take an hour to *read the article*, do some other research, and post some meaningful commentary. Those who post fast seem more likely to spout out their gut feelings.
To sum up: The people who post first are likely to be avid slashdot readers and more zealotous. Posts that are made soon after the article goes up are not as likely to be based on facts.
On hot trigger issues such as this one, I have read comments soon, then comments later and been pleasantly suprised by a couple better posts that get moderated later. Often on looking further, I notice that there are several more that I would have modded higher than the ones that are modded higher.
Let me try to illustrate this with a graph:
PostQualityv sTime:
|high
|
| +---+
| +++--+
|+-+ +---+
|++ +---+
|++ +---------------
|++
|+-+
|++
|++
|
|low
+-----------------------------------------
time-- ->
Sumofmoderationdone
|more +-------------------------
|+-----+
|+--+
|++
|+
|++
|+
|+
|+
|+
||
|
|less
+-----------------------------------------
time--->
As you can see from the graphs, I think there are a lot of good comments posted later that don't get moderated, while a lot of earlier comments that might not be quite so good, do.
I suggest the golden moderation system.
You get 5 moderator points.
2 of the are gold.
2 of them are silver.
1 of them is bronze.
gold points can be used on any post at any time. Silver points can be used on posts attached to articles that are more than 2 hours old. Bronze points can be used on posts attached to stories that are more than 1 day old.
I think this would really do wonders for Slashdot
I think you were reading a different article.
Tom
I have discovered a wonderful
That's very true
Several reasons are possible. I could imagine that they finished more than one set of benchmarks at once, so they have more than one story. At the same time, they don't want to flood the site with benchmarks and stories. So they keep one of 'em on the shelves.
Or they do all the testing one weekend (or two weekends), and the story around the charts some time later because something more important came up in their lifes.
Also, somebody might have corrected some spelling mistake on the pages, which would influence the date when it was last modified.
Veritas also has an outstanding Java based admin tool for their cluster server software package. It's incredibly snappy, and helps to take away some of the stigma that is usually associated with Java based interfaces being slow.
Yeah, that looks pretty simple. I have not looked at Smalltalk too much but the GOF "Design Patterns" book and people into OO theory obviously like it.
But what if you want to break out of the iteration when a particular element is found?
meaning, ...if(eachElement.equals(whatImLookingFor)) {
break;
}...
KidSock
ObAOL: Me Too.
:(
I can't really tell what the real problem is here. There seem to be two symptoms: Loads and loads of +5's and trigger happy posting. Easy kill solutions would appear to raise the moderation limit to 10, and have an hour - SIXTY GODDAM MINUTES - before you can post. Hopefully somebody somewhere will actually read the story before zapping in with xxxSux or xxxRocks.
But there's a more fundamental problem going on, god knows what it is but maybe you're right - maybe I'm back to usenet.
alt.peeves anyone?
Dave
I write a blog now, you should be afraid.
Since each iteration in smalltalk's do: statement is actually just executing a block (i.e. anonymous inner class), it's effectively a method call. So, you just have it return.
-Stu
Sadly enough, I'm dead serious. That damn thing taunting me over and over. I couldn't take it anymore. I went to that site with a vengeance and whooped his ass first try.
:-)
I now have a nice treeloot.com stuffed monkey, complete with boxing gloves, sitting on top of one of my speakers at work. Yes I feel better now
In this interview some Sun engineer says the next Java release will definitely support wheel mice with Swing. No word on how this release (1.4, 'Merlin') will be out, though.
Plus, the tests on Win32 are pretty meaningless because Win32's system timer is not precise enough to generate meaningful numbers when you use System.currentTimeMillis() . (AFAIK - someone correct me if I'm wrong)
Bottom-line: Try IBM's JDK 1.3.0 . Failing that, try a better benchmark which tests other aspects of Java performance, not just how fast you can create objects. But most importantly, don't trust a benchmark for anything - test real-world, production code. That's pretty much the only way you'll get a real idea if Java is suitable for your needs or not.
Okay, I can understand being happy when something like NVIDIA's OpenGL (which is very Windows oriented) performs nearly as well on Linux. However, does Linux Java being slower than Win32 Java "rock?"
A deep unwavering belief is a sure sign you're missing something...
Is it about the companies who got together to actually agree on something. Is it the marketing people read and propigate without knowing what it really means.
It's partly marketing, but it's also the great number of premade classes to make most things simple. From decent string-handling, to ease in writing GUIs (Swing or the old AWT), to simple and powerful server programs (servlets). Portability is something that adds to the combined total of all that. You're writing for a virtual machine, which means that you have the choice of writing on the same platform everyone else is, regardless of the computer platform the program's running on. That in fact is what Sun is using legal force to ensure.
If you're willing to pay a good bit, the documentation is very good, and the online JavaDocs are a good substitute. Many books are free at http://java.sun.com/docs . The hole in documentation is in the servlets; you're pretty much looking at O'Reilly for that.
Syntax is passable and reasonable. If you really care about semantics, use Scheme or something. No one really complains (in real life) that Java imposes OOP on the programmer; it's trivial to stick everything in a public class and make everything static. I've certainly done it for very tight apps.
It really goes to show how few coders really know that much about their tools and why they use them.
:) PERIOD
Together, we are strong; Apart, we are stronger.
I'm the author of the "Java on Linux" article in the August Issue of Linux-Journal. Please note that I never claimed this benchmark to be "rigorous" or "complete" -- because it isn't. All it is is a simple benchmark to measure the performance of Java programs in terms of how many objects can be created, used, and discarded in a given amount of time. I believe this is fairly typical behaviour for OO programs, but, it does in no way justice to all aspects of a Java implementation (such as JDBC, Java 2D, Swing, etc.). In fact, no single benchmark could do this.
= ======
;-)
Quite a few people sent me e-mail with comments, suggestions, and criticism. I prepared a summary to these questions and mailed it to the authors. I'd like to post the summary to this discussion group as well, since many of the questions and objections turn up here too.
So here it is....
REPLY TO LINUX-JOURNAL ARTICLE ON JAVA IMPLEMENTATIONS
===============================================
1. GENERAL
1.1 IBM JDK 1.3
At the time I wrote the article, the IBM JDK 1.3 was not available
yet for Linux and therfore it wasn't in the original article.
When it was released, I immediately ran the benchmark again
and obtained the best results I have ever seen on Linux. I sent
a short summary with the results to LJ and asked if they could
add a "last minute news" box with the results to the end of the
article.
Well, the LJ editors decided to place the IBM JDK 1.3 results in
the introduction section of the article, where they are a bit
out of place.
1.2 Article Headline: "The Java interpreter on Windows is faster than
the fastes JIT available on Linux..."
This headline was selected by the LJ editors, not by myself.
After running the benchmark with the IBM JDK 1.3, it is actually
no longer true, but I wasn't able to rewrite the article in the
short time after IBMs JDK 1.3 became avaible and before the
article went to press.
1.3 Borland Delphi
Someone pointed out that Delphi would be simpler than Java
and as efficient as C. I'm not familiar with Delphi, so I cannot
comment on this. However, as far as I know, there are no open
source implementations of Delphi, so at least for me it's not
a candidate for the open source programming language I mentioned
casually at the end of the article.
1.4 Why was Tower/J not included in the benchmark ?
Tower/J is a commercial product. Although they do provide
evaluation licenses, you have to justify _why_ you want one.
Since I was unsure if doing a simple benchmark for LJ would
be justification enough, I didn't bother to ask.
2. QUALITY OF THE JAVA BENCHMARK
2.1 The benchmark is not indicative for real world Java applications.
Yes, this is true. No single benchmark can do justice to all
aspects of a Java implementations, so I picked something very
simple (ie. creating objects and calling methods on them) which
_all_ programs do (well, at least all reasonable OO programs).
2.2 Flyweight Pattern
Someone pointed out that applying the flyweight pattern would
improve the performance of the code by a factor of 5. This is
certainly true, since flyweight eliminates the overhead of
creating 500k objects by using just one object and associated
IDs. I agree that this is what every sensible software engineer
should use in a real world program of production quality.
However, the intent of the benchmark was to compare the relative
performance of different Java implementation on Linux in terms
of "how much does creating an object cost ?", so saving on the
number of objects to be created wasn't an option.
3. THE C++ BENCHMARK
3.1 Why is there such a big difference in performance between compiled
C++ code and compiled Java code ?
I'm not a compiler implementer (ask Per Bothner of Cygnus Support,
he would probably know), but I think that the overhead for garbage
collection and synchronization mechanisms for multithreading are
likely explanations.
3.2 C++ Optimization
I didn't use any optimizations when compiling the C++ program,
because I didn't use any on the Java benchmark either.
3.3 By reference vs. by value semantics
Someone pointed out that replacing "ptarr" (which is an array
of pointers to "PerfTest" objects) with an array of "PerfTest"
objects will result in a 20 fold performance improvement.
I can believe this, since it eliminates 500k calls to "new
PerfTest".
However, this is not the point, since Java has no comparable
mechanisms
for this. In Java, all objects have "by reference" semantics, there
is no "by value" semantic for objects. This is one of the reasons
why Java is simpler than C++ (and also why it's slower than C++
)
3.4 Missing "#include" statements
The #includes at the beginning of the C++ program (listing 2)
should
read like this:
#include
#include
#include
Since I sent the original article in HTML format to LJ,
their HTML converter probaly ate the includes, thinking
they were some kind of obscure markup tags.
If you took offence at my comment, I apologize. It's clear that you understand the scope and limitations of your benchmark, even if the person I was replying to did not. Are you planning any followup Java on Linux articles in the future?
I am tired of benchmarks. I am tired of hearing about MySQL vs Postgres, Apache vs IIS, etc. That sort of benchmarking is not worthy of discussion and Slashdot should understand this by now. Hey. If Ingo Molnar writes a kernel-space web server which will be available in upcoming Linux distributions, that's interesting and that's news. But please. Please. PLEASE stop with all of these useless benchmarks. All they do is provoke people and lead to endless arguments about nothing at all.
Dave Bailey
Basically, there was a little blurb under "Conclusions" that said "Oh yeah, it's fast on Linux too, and sometimes faster." Whee! But this benchmark was not meant to compare java across platforms, and didn't even run anything on Linux.
If the app runs for more than 5 minutes without crashing, version 1.0, baby.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Java is not slow; Java has some slow spots, which is different -- it affects you depending on the job. For example, Java has no select() yet so you're forced to have one thread per simultaneous connection in servers (very bad). Java2D's implementation sucks too, because it doesn't use available HW acceleration. Some libraries can be improved. And the JVM comes with a price in memory.
- security-and-object-persistency-services that I wrote recently just rocks (but that's because we're not into the 1000's of users).
On the other hand, the server-side-JSP-based-app-including-our-own-CORBA
According to http://members.ping.at/theofilu/netsc ape.html, Netscape gets its problems from memory management functions (big surprise there) in the the libc.so.x.x.x library. I'm trying the fix recommended on that page, sounds like it might help clear up the other Java problems.
Could it be that JDK/JRE v1.3 for Linux has not been released by SUN for Linux yet?
Never express yourself more clearly than you are able to think. --Niels Bohr
the graphics issues are simply a matter of LinuxJava accessing the hardware directly.
No. A better design is to have a rendering extension in the X server that knows everything about the hardware, and a Java library that just calls this extension. Trust me, you don't want your JDK's libraries to know about the difference between a G200 and a G400.
Currently, X11 rendering is inadequate for Java, and e.g. Java2D does all its rasterisation client-side and blits it to the X server.
There is a lot of XFree86-related work aiming to develop rendering extensions:
Not only is this not representative of most real-world programming tasks (it checks the gc and allocation code more than anything), but he didn't perform simple optimizations that would have helped him big-time (like loop unrolling). He also apparently didn't read the gcj docs, which point out that gcj's bounds checking is much slower than it should be, so if you don't need it, you can turn it off. Since he does 1.5 million array accesses and does all the bounds checking himself with loop termination invariants, bounds checking is a fairly important -- and unnecessary -- constant multiplier, I'd say. :-)
~wog
What a lot of people fail to realize is that a lot of "java performance problems" are caused by sub-par java programmers who don't understand how costly some operations are. Another entire class of performance problems are caused by bad algorithms. An O(n) algorithm coded in QuickBasic will outperform an O(n^2) algorithm hand-coded in assembly language for most possible inputs.
OK, so all things being equal, using smart algorithms, and not abusing the language, java is still a bit slower than C. Big deal! In most cases, it doesn't matter. Server-side apps are blocking on I/O most of the time anyway; client-side apps are blocking on user interaction most of the time. For projects with hard real-time requirements, you have the RTJ standard; if you're really speed-hungry or are doing serious systems work, then you can write it in C.
However, my employer could buy a middle-range Sun workstation for what he pays for my time in a week, and I'm a lot more productive in Java than I am in C. Furthermore, because I pay attention to engineering and design issues, other engineers can re-use and subclass my code without modifying it. If I've used good algorithms, avoided stepping on the GC, and steered clear of known performance problems (like the + operator for Strings and the unnecessarily synchronized Java 1 collection classes), then my code is probably fast enough. If it's not, then it's a lot cheaper for my boss to requisition a faster machine than it is for him to pay me for an extra two months to chase pointers and re-model object-oriented systems in procedural code.
~wog
This is a common error for me -- "teste" means "test" in Portuguese (which is my native language), so I guess my language switch failed for just one milissecond. And I was not aware of any meaning for "teste" in English (my knowledge of slang is limited) but I can guess from the context. :-))
Want to write system level/embedded stuff. Use C or lower-level assembly or even lower level VHDL hardware description langage if you're crazy!
Want to write networked apps/server stuff. Java rocks at this. If Java is too slow, buy a faster machine. Buying a 8000$ machine is nothing compared to paying four programmers four more weeks to do the same in C on a 3000$ machine.
Obviously, you'll learn that in engineering, there are a lot more considerations than technical stuff.
...although I guess the JDK still needs to be updated to use XFree4's DGA. I hope Blackdown's 1.3.0beta is out soon, as they're more likely to be first with such optimizations.
Anyway Linux 2.2 can be more scaleable, you only need to avoid native threads (like TowerJ does). OTOH, native threads are good with many CPUs. An implementation that uses multiple native threads, but can multiplex many Java threads per native thread, is probably the best.
Thanks for the tip, I will try to find this edition of LJ.
:) Now serious - any advocacy group will have some excesses, some people on a jihad, some kids pretending to be experts. And not being myself a Linux (or any OS's) advocate, I frequently read in /. too much BS written by pro-Linux zealots. One always needs to filter. As a long-time member of the JL, I already know the frequent posters so I can focus in the good posts and ignore the noise (unfortunately we miss something like /.'s moderation).
On the "collective IQ" of the Lobby, well, at least we don't have every single thread beginning with "FIRST POST!!" messages
I've been using IBM's JVM for linux for a while now, and I must admit that it's pretty fast. The blackdown ports definitely can't beat it. What bothers me though is the graphical implementations of most VM's: awt and swing. I've been running a development tool which is implemented in Java mainly using Swing. The main problem is that it runs perfectly with SUN's VM in Windows NT 4.0. I've tried to run it in Linux using IBM's VM, but that was a disaster: the user interface was slow, stops responding at strange times, and eventually the entire application crashes (don't ask me if the application crashed or the VM crashed, I am not sure anymore). If I don't run graphical applications (usually the ones I write myself :))
I don't have any problems. In fact I was very pleased with the performance of that IBM's VM.
To me, a VM implementation for linux will only deserve the adverb 'rocking' if it has IBM's speed and Sun's stability (when it comes to graphics)
Add to my list of complaints that dumbass moderators, who have knocked my original post from a +2 to 0 with several "offtopic" mods (shrinking my karma in the process, of course), have seen fit to give MrBogus' post a rating of +4, even though it appears in a thread underneath my post and deals with the same material, which is supposedly offtopic.
You can't have it both ways, meatheads.
slashdot broke my sig
I understood the poster's comment to mean that moderators should be given ten moderation points to work with, not that posts should enjoy an upper limit of ten points.
The problem is not the posts that get moderated up, it's the posts that don't and the moderators that blow their load on the first 30 posts.
There should be no negative moderation, it's pointless. Start all posts at zero by default, adding a point or two for merits, then allow the good posts to accumulate positive moderation points.
"Yeah, but what about crappy posts that get moderated up?" Get a clue. A post might get one or two mods you think it doesn't deserve, but if four or five moderators think the post merits a bump, that's a pretty good indication that it deserves the increased exposure.
slashdot broke my sig
Erm, idiot, if you don't like the Linux bias, go somewhere else.
I've been reading Slashdot since day one. I found out about Slashdot while looking for AfterStep applets for my Linux box. Yeah, it has a Linux bias. Get over it!
Stating on Slashdot that I like cheese since 1997.
On the server side it is different. Java is a very nice language to develop in. The class library is HUGE and having the flexibility to support several platforms at the server is very good and something we surely will take advantage of in the future. It seems to be easier to optimize server side JVMs also.
Java is here to stay, especially at the server. Those who flame Java for its weak points (small client applications) should look closer on the areas where it rocks, before discarding the language as a whole.
It isn't pretty. All of the Windows solutions beat all of the linux solutions, inlcuding gcj.
:)
Java may be adequate on linux, but I really don't know how you could conclude that it "rocks".
The article actually concludes with this very point, in fact, something along the lines of "The Linux JVM is almost as fast as its Win32 counterpart".
What's impressive for the Linux side is how far it's progressed lately - support for 1.3 will help an awful lot. The main cause for difference in speed is the amount of time Java has been available and the amount of time spent improving it on each platform - years for Win32, almost none so far for Linux.
I don't quite get the "rocks" part myself either, but it's a definite improvement
Fross
When java finally hits Mozilla, I'll wipe Netscape from my disk drive.
Figures don't lie, but liars figure. Enough with the benchmarking! ibm gets to pound it's chest today, Sun tommorrow, and linux the day after that. Could we get some articles boasting specific implimentations, at least it would be an interesting read, instead of looking at bar graphs all the time which mean nothing in the real world. If I see one more benchmark i'm calling reno up!
Saying that Java is hype because you used it to write software which is not its core competency is an instance of a poor worksman blaming his tools
Java's GUI API will always be slower than Native GUI toolkits. In most instances if the app is complex then it'll be almost unusably slow. Heck, even Sun has canned most of its Java GUI tools because they became unusable the larger they became.
Perl is the king of text processing languages (no contest) and C++ gives more fine grained control of sockets than Java.
Now for medium to large scale, cross platform, multithreaded, easily extensible, middleware applications that will need little or no maintainance but are easily maintenable, Java(TM) cannot be beat.
PS: Your rant is similar to someone bitching that C sucks because it is poor at text processing even though C was designed as a portable assembly language.
The Queue Principle
First of all, IBM has done more with Java than Sun... one of the first useful Java applications I ever tried was their Java IRC client, which did everything an IRC client should. If anyone was going to do a quality Java implementation, the people at the IBM alphaworks would be the ones.
Also, one shouldn't dismiss the Open Source contribution to this. Having the ability to examine the kernel source in detail makes it that much easier to tailor your Java implementation so that it best integrates with the kernel. With the highly closed nature of Windows, developers have to guess how to best integrate with the complex APIs and SDKs of Windows.
Java may actually take off only about four years after it was supposed to be The Next Big Thing in programming languages. With APIs like Jini and Personal Java, Java may actually find a niche in PDAs and Internet Appliances...
I've been running the blackdown jdk in a production environment for over a year now. It has been nothing but stable and seems pretty fast. I did try out the IBM jdk 1.3 and was very impressed... until I ran apache bench. It crashed within seconds of a 100 concurrent user test that I run with no problems on blackdown. Has anyone else seen this? It's a new port, so I will try back with the next release.
I think it is interesting how far java has come but am I the only one who fails to see what all the hopla is about. Is it about the companies who got together to actually agree on something. Is it the marketing people read and propigate without knowing what it really means. Someone please enlighten me. Please not some fanatic who is on the bangwagon just to be a part of something, just someone who knows the true importance of it and can explain it without telling me it runs on a lot of platforms.
"What a waste it is to lose one's mind. Or not to have a mind is being very wasteful. How true that is"
Vidi, Vici, Veni
It would help if you would specify which JVMs you were talking about. Otherwise, you experience may no longer be relevant. Under Linux, our full-blown options include Blackdown's JDK 1.2.2 port, Sun's JDK 1.2.2 with Borland JIT, Sun's JDK 1.3 with Hotspot and IBM's JDK 1.3 with IBM JIT. The posting was primarily about IBM's JDK.
I don't think GCJ is very usable right now. It is probably not appropriate to extrapolate from the performance of a very immature compiler to make assumptions about more mainstream and mature JVM solutions.
So there's too many people Karma Whoring for 5s and your solution is to raise the bar to 10? Why? To seperate the truely good whores from the mediocre ones? The problem is not the posts that get moderated up, it's the posts that don't and the moderators that blow their load on the first 30 posts.
In my book, we need more negative moderation and less positive moderation. I'd be perfectly happy with a maximum of 3 if you could moderate people down for reasons such as "Stupid", "Wrong", "Waste of Bandwidth", "Bitchy Old Timer", "Karma Whore", "Didn't Read the Article", "Advocacy Post" and "Take it to sid=Moderation".
When I hear the word 'innovation', I reach for my pistol.
Strange... I've had nothing but problems with Java on Linux, no matter what version I try to run it always has a tendancy to hang up. The only success I've had is running Java in Linux apps on top of Solaris. Check out lxrun for more details. :-)
Btw I run RedHat 6.2. Does anyone have any idea why it has such a hard time with Java apps in general? (Besides Netscape)
Last Modified: Sun, Aug 6, 2000 2:59:48 AM GMT
I'll second this. We had unacceptable performance with the Java 2 JDK that comes straight from Sun. If you're going to do Java on Linux, use the Blackdown JDK. As a bonus, the Blackdown JDK far outperforms the Windows JDK as well (at least for server apps, we don't do any GUI development).
--jbkeep in mind that Sun has always had a different approach to hardware and this is apparent in their software .. personally I find it impressive that they are able to maintain a good presence in the Intel market while producing their own (better) hardware all along. puts companies like apple to shame. their focus on interoperability, research, and development has undone most of the proprietary obstacles that have persisted since the mid-80s.
my biggest beef with the linux community is the lack of real innovation. ok so sun doesn't give everything away for free .. go write your own language .. develop your own ideas that are fundamentally different and stop copying everybody else .. imitation becomes the highest form of flattery.
"Javalobby stats should not be trusted - my experience is that Javalobby has the lowest collective IQ of any community tech site on the web, and their articles are typically mindless advocacy with no useful data."
;)
Funny, that's just what they say on JavaLobby about Slashdot
Moderating down an AC post should be less expensive, perhaps free, to the moderator (if the AC post has not been previously modded up.)
The survey is here, go and vote. Recently, a petition was put forward to open source javadoc (the Java sourcecode documentation tool), but Sun hasn't responded (possibly due to lack of attention from the media). I think if we really bug Sun about this, we might get an official response (*fingers crossed*).
As to the topic at hand, my primary Linux JDK for development is IBM's. It's excellent, and very fast - I haven't had any problems. Sun's 1.3.0 JDK hasn't even been officially released for Linux or Solaris yet, so there's not really much of an alternative at the moment.
Just what is the problem with getting a JVM into Mozilla on Linux. The rest of it is pretty pleasant (at least, the nightly builds are), and I can understand the lack of encryption, but no JVM? C'mon, I switched all my stuff to css, and it renders wonderfully in ie on windows and m17 on Linux, but I have to dip back into communicator if I want to visit anything with an applet. Bah!
Time to go back to Usenet. I am thinking about it as well.
How can one say that Java on Linux "rocks" when something as basic as simple audio support is not usable? Please note that I am only ranting about client-side use of Java here. It might be that Java "rocks" on Linux as long as you are only using it for server-side stuff, which is probably what most people will use it for anyway...
After seeing a few posts about how slow Java is I must inform you that Java is not meant to be fast. It is just very good as a programming language and correctness is paramount to speed. It's object oriented functionality is basically unparalleled in the industry. It is much easier to write programs that take advantage of OO constructs than all other OO languages(if you think Smalltalk or something else is just as good or better I'd like to hear your arguments). Sure C++ and many other languages have these features but in practice is has been proven that most people don't know how to use them properly so brings more programmers closer to the far superior OO world.
This is where the problem lies. I would guesstimate that 9 out of 10 coders using an OO language don't really understand OO principles. They might claim to understand, but in reality their code is modular at best. If you have one well designed high level OO construct, your program it will be more that 2x better(I know you probably don't see why but this is a VERY BIG deal).
If one person with great OO skills writes the high level design the 9 other coders can work happily writing their "pseudOO" code and you can still end up with a good application. If they really screw up their little piece you can very easily replace it because the OO abstractions prevent these mistakes from transcending the system.
A well written Java app can be quite fast too. It's the many VB programmers who jumped on the Java bandwagon and use IDEs, misconfigured application servers, producing what they think is good code that give Java a bad wrap.
KidSock
suns JDK on linux sucks rocks. it tends to lock up under heavy loads. i've personally observed this several times. blackdowns 1.2.2FCS works as well as suns JVMs on solaris do. note that most JVMs are better off with a max of 125 threads/JVM. of course with java multiprocessing/mutlithreading is built into the language from the ground up and as a general rule i run at least 4 independent JVMs per machine (500 concurrent users) for decent performance.
Order in which JDK 1.3 is/will be released for various platforms:
Has to be a tad embarrasing for Sun!
--
DWR is Ajax for Java
It was one of the few places I worked at that had an active hostility towards Linux. Needless to say, I no longer work there.
Looking at these benchmarks, I do not think I would be able to convince any of my ex-co-workers that Linux is ready for heacy-duty Java yet.
I note that Java on Linux has caught up in a number of ways, but still has a way to go with:
- Scalability
- Graphics performance
The scalibility issues should be much less of an issue when the 2.4.x kernel comes out (knock on wood), and the graphics issues are simply a matter of LinuxJava accessing the hardware directly.Anonymous so my ex-employer doesn't get on my case for breaking any NDA I may have signed
Who the hell cares about cross platform capability once IBM puts Linux on all of its hardware platforms as they have anounced? Just look at www.ibm.com/linux . I can kick JAVA's ass on Windows and soon on Linux with Delphi ( www.borland.com/delphi ). Who the hell needs JAVA when you can create raw, powerful, nativley compiled exe's in Delphi for Windows and soon in Linux? There is NOTHING you do in JAVA that you can not do in Delphi. If so, please show me. Who the hell needs JAVA when you can create "native" Apache modules nativley compiled in Delphi for Linux? JAVA is childsplay, get serious and learn a real language like Delphi. Those wannabe programmers that use JAVA are a joke. There is always a need for speed. Period. No matter how fast your CPU is. Got that? With Delphi for Windows and Linux and possibly Apple and other platforms, who the hell wants JAVA crawling along as pathetic as JAVA is? And, raw speed is only one of MANY great features of Delphi (OO Pascal). God I hat this Java crap. Just like when VB for Win came out back in 1991. Give a man a toy, he plays with it. Give a man the best tool, he starts producing reliable, stable, and fast products and services. Grow up people, smell the coffee or something, just WAKE UP!!!
I have 100% proof that you're wrong. I once saw a C++ program which was slow and buggy to an even greater extent. Therefore C++ sucks more than Java. QED.
Do you see the gaping hole in your logic yet?
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
People don't complain about the execution speed of Python or Perl because nobody touts either Python or Perl as being fast. When you are working with a scripting language you are optimizing your development time, not execution time.
The Open Source community has long been skeptical of Java for many very good reasons. For example, as you yourself state many of the core Java libraries are painfully inefficient. Another problem with Java is that it has been touted from it's inception as a "Write Once Run Anywhere" language, and yet the Linux and BSD versions of Java have historically been late, buggy, and incomplete. In other words, Java has been a "Write Once, Run On Solaris Or Windows" language up until very recently. Perl and Python both work very well on the Free Unixes, and (speaking as someone who tried Java first) generally performed as well or nearly as well as the more complicated Java. For example, Perl will completely destroy Java if the task includes a lot of text manipulation. And comparing a GUI written in Python/Tkinter (or better yet wxPython) to a GUI written in Swing is ridiculous (or has been until recently on the free Unixes). The Python GUI would almost certainly use less memory, and be more responsive.
The killer has been that Java has historically had all the speed of an interpretted language and all the complexity of C++, hardly a compelling combination. This is just starting to change, but it will be some time before Java loses its stigma. In the meantime the hackers that have chosen Perl or Python have very little reason to switch. They are, by in large, quite happy with their choices. And it really isn't that hard to implement a solution in Python (or Perl) and then optimize the slow bits in C.
well thats java on the rocks
--this mesage will self distruct in five seconds--
Truly beautiful man. Maybe part of the problem are the moderation guidelines which I believe encourage positive moderation rather than negative moderation. That and moderators cruising at +2 (something that I'm guilty of).
:)
I can't help feeling that the moderation points evaporating after three days doesn't help either. I'd rather save mine for a couple of weeks and give +1 to something *genuinely* insiteful (spell?).
BTW, I have problems with that word. Does it mean "as in to shine a torch on a previously dark area", "sharing of insights", or more "insightment to riot".
Anyway, I started this with the idea of adding to your list of negative moderations, but you seem to have pretty well covered the bases there.
Dave
I write a blog now, you should be afraid.
BTW: According to HTTP headers the article was posted on the 6th of August.
Not convinced? Just look at that "Punch the monkey and win $20!" banner ad. That thing is Java. And it seems to run slower when you run it on a faster processor.
Also, Quake III is partially Java powered (the main game code). However, it can also take DLLs (but John Carmack prefers QVM for its better file system security), and a group of hackers recently converted the main QVM files into DLLs. These run 20% faster than the QVM files, making mod developers wonder if they've done the wrong thing by learning QVM.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
If your "Java enterprise system" needed an E10K to run acceptably, then the "disservice to the programming profession" is the person who wrote it. Nowhere in my post do I advocate writing inefficent code. I do advocate using Java; you may be arguing that it is not up to the task. However, Java performs well enough for the vast majority of server-side development, and the gains reaped from using Java -- in reduced development time and reduced maintenance time (in the real world, other people have to understand and work on our code, too) vastly outweigh any minor performance losses.
Wow, what a lot of whining here by the "java is too slow" crowd.
The right tool for the job. Look at what you need to do. Look into ways to do it. Choose the way that is right for your situation. If that means using Java on Linux great! If it means ASP on NT, fine (insert anti-MS statement here).
I'm currently using the 1.3 Java 2 SDK on an NT box for some development we are doing. The data access(JDBC) and networking (Servlets) works great - quite zippy, at least for our needs. The client (a custom applet) renders a little slow but we accept some slow rendering speed in order to get the peculiar UI our client wants (a round component with buttons that are pie wedges a la Trivial Pursuit pieces each one of which pops up a dynamically created menu with database data in it). We choose java because it was one of the few languages which allowed us to do all these disparate programming chores and keep the code clean and maintainable. We went from zero to prototype in 5 days.
Now I'm sure we could have done this in a number of different ways (although we couldn't figure any others).
The story was about how much the IBM JDK for Linux has improved in terms of speed, how it's almost ready to do graphic intensive stuff like desktop apps and such. If you really need that couple of extra milliseconds, use something else. Just stop whining about it.
I personally don't like perl (my own opinion) but I don't go around slagging it - for some things its probably the best tool for the job.
Never by hatred has hatred been appeased, only by kindness - the Buddha
It isn't pretty. All of the Windows solutions beat all of the linux solutions, inlcuding gcj.
Java may be adequate on linux, but I really don't know how you could conclude that it "rocks".
Javalobby stats should not be trusted - my experience is that Javalobby has the lowest collective IQ of any community tech site on the web, and their articles are typically mindless advocacy with no useful data.
We have a canadian specific promotional site running on a linux cluster (ultramonkey/LVS) We are running: ApacheJServ-1.1.2-1 IBMJava118-JRE-1.1.8-3.0 IBMJava118-SDK-1.1.8-3.0 and default apache install (1.3.12) of VA Linux 6.2(1?) All seems pretty stable, IBM has done a good job and Java on the server side is a very real, viable technology. While it may be slower than PHP (and others) it's still very viable (at least in my eyes, I make no claims that they are the same as my employers') Nearly the entire site is open source with the exception of a single macromedia director application.... (here comes the shameless plug), it's www.aztektrek.com check it out, win a new Aztek car from GM.