Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Java Rocks On Linux 156

Posted by emmett from the benchmarks-for-all-my-men dept.
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."
This discussion has been archived. No new comments can be posted.

Java Rocks On Linux More

Java Rocks On Linux

Comments Filter:
  • 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
  • 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.

  • 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.
  • If you know what you're doing, the situation is different.

    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.
  • Strings are immutable. You ought to use StringBuffers and the append() method. Most JVMs will optimize a statement of the form
    System.out.println("notice: " + bar.numFrobnications() + "frobnications");

    to use a StringBuffer, but they won't do it for code within loops, like
    boolean doneYet = false;
    String foo = "";
    while(!doneYet) {
    foo = foo + String.valueOf(someObject.someMethod());
    }

    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 [slashdot.org] 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...

  • 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.

    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.

  • The JVM's default optimization is quite simple-minded. That code will work like you say, but here is an example [slashdot.org] which won't be so lucky.

    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

  • 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.

    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...

    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 ... translate to C++. :-p Should only take a couple of months...

    BTW you can read my Tech File [flipcode.com] 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.
  • There is NOTHING you can do in DELPHI...
    1. ... that you can't do in ASSEMBLER.
    2. ... that you can't do in PL/I.
    3. ... that you can't do in LISP.
    4. ... that you can't do in PILOT.
    5. ... that you can't do in TURING.
    6. ... 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.

  • 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.
  • I wonder how IBM's new embedded Java VM for Linux [oti.com] compares. It's available as a beta for x86 and PPC Linux. MontaVista recently made an announcement that they'll be distributing it [linuxdevices.com] with their release of HardHat Linux.
  • 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 :-}

  • An amazingly unfortunate typo (Score:4)

    by FatOldGoth ( 207461 ) on Sunday August 20, 2000 @10:17AM (#841423) Homepage
    Well, at least I assume it was a typo.

    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 make my living that way. Of course I am professional then.
  • Yes, it is interpreted. The JVM is an interpreter. Your confusion probably results from the fact that Java code is said to be "compiled" (e.g. javac foo.java => foo.class). But the Java "compiler" is not a compiler in the same sense as a C, C++, or Fortran compiler. The Java "compiler" simply takes the text file you give it and outputs a binary file which is then *interpreted* by the JVM.

    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

  • I have solid evidence that Java is slow and cumbersome: The IBM Point Of Service system.
    Not at all. The only thing you have evidence of is that the IBM P.O.S. system is slow and cumbersome. This has very little to do with the programming language used to implement that system, but instead indicates that the system was poorly designed. A poor design, of course, is poor no matter what programming language or tools are used to implement it.

    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.
    _____
  • 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.


    --

  • 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 [blackdown.org] 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

  • People who say that Java is slow are correct, for the most part. Even with the best JVM, Java cannot approach the speeds of a well-designed native-code application.

    You forget that Java can be compiled too. Just look at GCJ [redhat.com]

    Java is really three things. JWZ has a nice paper [jwz.org] 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.

  • 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've heard of Java Beans, but "Java Rocks"? (Score:4)

    by glitch! ( 57276 ) on Sunday August 20, 2000 @09:52AM (#841435)
    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.

    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 :-) I have enough serious rambling yet to finish.

  • ...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".

  • 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.

  • Re:Java is plainly too slow. (Score:4)

    by deusx ( 8442 ) on Sunday August 20, 2000 @01:27PM (#841439) Homepage
    Okay, repeat after me:

    HARDWARE IS CHEAP. PEOPLE ARE NOT.
    HARDWARE IS CHEAP. PEOPLE ARE NOT.
    HARDWARE IS CHEAP. PEOPLE ARE NOT.

    So, Java's a little slower on the runtime versus native code. Quantify that difference (call it X).

    On the other hand, I've heard (and experienced) that writing with Java and its APIs is much faster and easier than learning and writing code to various OSes and their bare-metal system resources. Quantify THAT difference (call it Y).

    So, what's the per-unit cost to compensate for X across multiple forms of hardware. What's the per-unit cost to compensate for Y across OSes, people, and systems.

    I'd be willing to bet, were this all actually well formulated as an equation, that you'd find we really don't give a shit anymore about how blindingly fast a given programming language can be if you're hacking close to the hardware. Hardware is cheap, just throw another faster CPU at it. People, however, are much harder to upgrade.

    hen a programmer just has to know one pretty simple language and API, rather than many OS quirks and tricks and system-resource details that distract from the main task at hand, programmer cost goes down. Make it easy for the people, and it becomes so much cheaper that we accept a margin of performance cost on our easily improved hardware.
  • 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".

    For instance, in ST I can iterate through a collection like so:

    myCollection do: [ :eachElement | eachElement doSomething ].

    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.
  • hmmm once again, obviously you havent used enough java.

  • Re:I give up. (Score:1)

    by Anonymous Coward
    Could you please explain what you are referring to, or could someone else give it a try who knows this moderator and what his problem might be?

    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.

  • More Java benchmarks (Score:5)

    by harmonica ( 29841 ) on Sunday August 20, 2000 @10:18AM (#841443)

    Fact is, you can't say Java is fast or slow, it depends a lot on the context.
  • "It runs nicely, the GUI's concept is simple to understand" What is your point? "runs nicely" really means nothing. "GUI's concept is simple to understand" I agree. But when it is 20 levels down the hierarchy to Object to get a FlashyImageButton, I would not doubt how slow it could get.
  • 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.

  • Re:Java is plainly too slow. (Score:4)

    by macpeep ( 36699 ) on Sunday August 20, 2000 @10:23AM (#841446)
    Interesting, guess linux should be rewritten in Java.

    Uhh... Use the right tool for the right job. I'm not, of course, saying everything should be done in Java. I'm just saying that for many things, Java is great and it has it's place - as does many other languages and technologies.

    I just read an article where Linus Torvalds says his siblings and grandparents use Windows cause it has better support for the apps they need. Fair enough. He doesn't jump out the window cause of it or start crying that Linux is the only way to go. The same attitude might be smart when dealing with languages and software platforms. A professional software engineer uses the best tools for the job.

  • 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.
    I have a few observations and theories on this point.

    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

  • True, but it does tell us one thing, the benchmarks are a minimum of 2 weeks old.
    That's very true :-)

    I'd suspect that the benchmarks went up on the page as soon as they were ready. I mean, why would you delay posting them once they were completed?
    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.
  • Ho hum.

    Yes, Java is slower than C or C++. Does it matter? Yes, if you're doing graphical stuff or heavy GUIs. Not at all if you're doing server-side stuff, where Java's built-in multithreading and exceptions kick ass, so to say.

    Java is brilliant for a lot of stuff, less brilliant for some others. Right tool for the job, you know?

  • 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 :(

  • 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.

  • 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 [sun.com] 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.
  • That benchmark is shamefully poorly done. It doesn't include IBM's 1.3.0 JDK (which is, after all, what this story is about) - on my system, IBM's JDK does that so-called 'benchmark' very fast. I don't want to shut down X et al to doublecheck, but IIRC, IBM 1.3.0 can do ~945 objects per ms on my Celeron 500, 128 MB RAM, Linux 2.4.0test7. Since that's a different kernel and really different hardware, it's obviously apples-to-oranges, but it should give you an idea how fast IBM's JDK is.

    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.

  • Is it just me? (Score:3)

    by be-fan ( 61476 ) on Sunday August 20, 2000 @02:43PM (#841458)
    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?"
  • "Anyone can code a crappy app in C and say "woah! look, it sucks! it's slow!". That doesn't prove that C would be slow - it proves that the code sucks. In the same way, an amateur not knowing what he or she is doing with Java can see slow apps. If you know what you're doing, the situation is different. " From your arguments, I derive that Bill Gates do not know what he is doing. "Millions of Java coders and companies use Java" do not mean a thing at all. Why do not you mention that 99.99% desktop users use Windowz?

  • Re:JDKs (Score:1)

    by Anonymous Coward
    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.
  • Java is the first programming language to be marketed like a consumer product. It shows. Look at all of the suckers it has yanked it.

    It really goes to show how few coders really know that much about their tools and why they use them.

  • Benchmarks are hardly "stuff that matters". Benchmarking Java is a waste of time and I do not understand why this is considered news. Is it really such a big deal that Java is faster than it used to be? Java has been fast enough for web applications for a long time (all it has to do is be more or less equivalent to Perl, which isn't such a big deal considering that both are interpreted languages). People who decide to use Java don't do so because it's fast. They do so because they like Java, for whatever reason.

    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

  • If the app runs for more than 5 minutes without crashing, version 1.0, baby.

  • And what is your experience with Java, please? I've spent almost the last five years developing a significantly large scale Java app, and it is very very good for what I need from it. You may not have a need for a secure, portable, high level programming environment with decent performance and easy programming, but there are a lot of us who do and have found it in Java.

    It would take a moron to decide that Java or anything else is the perfect answer to everything, but to declare people suckers for saying 'hey, Java is really some pretty nice stuff and I get a lot of benefits from programming in it' is insulting and pretty close to zero content.

  • According to http://members.ping.at/theofilu/netsc ape.html [members.ping.at], 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.

  • Re:Read last month's linux journal (Score:4)

    by woggo ( 11781 ) on Sunday August 20, 2000 @11:15AM (#841476) Journal
    There isn't anything "rigorous" about Hirsch's "set of benchmarks", nor can you call it a "set" without qualifying; it was a "singleton set". He simply populated an array (in one for loop) with a half-million lightweight objects and then accessed those objects twice (in separate for loops). Just because he tested it with several JVMs doesn't make it a rigorous test.

    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

  • Re:Java is plainly too slow. (Score:3)

    by macpeep ( 36699 ) on Sunday August 20, 2000 @11:22AM (#841477)
    Not just CPU - but of course it also helps some in making the speed disadvantage less noticable. I have this old texture filler that I coded some years ago to test the speed of Java graphics and on JDK 1.1.4 (or .3 or whatever) it ran with about 8 frames per sec on a given texture on a given polygon on a given app on a given computer. Microsoft's jview clocked around 12 fps.. Then with JDK 1.2.0, it dropped to around 3 (!!) on some color models, but I wrote another version that used a color model without any alpha channel and the speed was now somewhere around 8 fps. Meanwhile, JDK 1.1.8 was clocking up to 15 fps. With 1.2.2, it's up to 17 and 1.3.0 is almost at 20 fps. This is still with the same machine, same texture, same app.. The computer I use for this is my IBM 390 laptop that has a Pentium 233MHz MMX. On my AMD K7 / 500 Mhz, I get over 45 frames per second using 1.3.0.

    The speedup is directly visible in apps that use GUI's - Swing in particular.

  • hardware time is cheaper than programmer time (Score:5)

    by woggo ( 11781 ) on Sunday August 20, 2000 @11:32AM (#841478) Journal
    Good points, mac.

    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

  • 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.

  • So there's too many people Karma Whoring for 5s and your solution is to raise the bar to 10? Why? To seperate the truelygood whores from the mediocre ones?

    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.

  • Java strong at the server, weak at the client (Score:5)

    by claes ( 25551 ) on Sunday August 20, 2000 @10:36AM (#841490)
    As a professional Java developer for a little more than 2 years, I have to say that Java has still a some way to go for client applications. Swing is still too slow, and garbage collection makes the GUI to freeze every now and then. Also, the Windows Look and Feel is not very windowish. For example, wheel mice are not yet supported by Swing, and this has been very problematic for us as our customers where used to use the wheel, and had a very hard time to accept it stopped working when we switched from AWT to Swing.

    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

  • Re:Java is plainly too slow. (Score:3)

    by Pentagram ( 40862 ) on Sunday August 20, 2000 @10:40AM (#841492) Homepage
    Java too slow? We've heard that a million times. Boring. It's quick enough for thousands of Java hackers out there.

    It's not as quick as C performance-wise, but you get a speed tradeoff in return for platform independence, greater stability etc etc. The vast majority of apps being written today do not need to be blindingly fast. It's much more useful to have them written faster and be easier to mantain, both of which are helped a lot by Java.

    I suspect most of the flame I hear against Java is from established C coders who are scared they'll have to learn a new language. Try it, you might like it. I use Java and Perl almost exclusively now. I wouldn't use C now unless I was feeling masochistic or had to do something really low-level.

  • What is your point? "runs nicely" really means nothing.

    You said:
    Have you ever used the swing JFC? If you have tried the demos included in the distribution, you know what I am talking about.

    I simply say that I'm programming an application that is quite a bit more complex than the demos and there is no problem with it. No flicker, no slow GUI refresh, no problem. I also get along quite fast because Swing is easy to understand. So whatever you experienced isn't true for me -- got it?! The statement '...try the demo and you'll know what I mean' is simply nonsense. My system is a P-II 350, so not exactly the fastest machine.
  • And what is your experience with Java, please?

    Heavy use since 0.9.

    Most of the time very frustrating - trying to use the various incarantions of AWT/Swing/whatever.

    On the server side, some serious data mangling and networking (perl/C++ destroys it in this repsect).

    Its a solution looking for a problem.

  • Will be fixed in 1.4, according to some guys in comp.lang.java.programmer. There already is a fix, but only for Win32...

  • You Used The Wrong Tools For The Job (Score:3)

    by Carnage4Life ( 106069 ) on Sunday August 20, 2000 @11:58AM (#841499) Homepage Journal
    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.
  • correction: public companies have to act in the best interests of the shareholders.

    "What a waste it is to lose one's mind. Or not to have a mind is being very wasteful. How true that is"

  • 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".

  • benchmarks "not dated" (Score:2)

    by Anonymous Coward

    Not dated, but must be at most a couple of weeks old.
    Apparently Emmet never heard of the "view page info" command. The pages state:

    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).

    --jb

  • Re:Read last month's linux journal (Score:3)

    by lgraba ( 34653 ) on Sunday August 20, 2000 @04:36PM (#841514)
    "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 ;)

  • Open Source Java? (Score:3)

    by nconway ( 86640 ) on Sunday August 20, 2000 @10:47AM (#841516)
    While Sun open sourcing Java might seem outlandish, I'd say it's a definate possibility. Sun has GPL'd StarOffice, and is a member of the GNOME foundation. I think the bottom line is that if Sun clearly understands it would be in their best interests to open source Java, they'll do it. After all, they're a public company like any other - they have to obey the will of the consumer. OSS currently has a mindshare among developers that can't be easily ignored.

    The survey is here [yi.org], go and vote. Recently, a petition was put forward to open source javadoc [yi.org] (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.

  • It's not a solution looking for a problem, it's just not a solution to every problem.

    If you're looking to build a GUI app on a single platform, Java isn't going to give you the best results. If you're looking for a server app to do text processing or data reduction, Java isn't going to give you the best results. If you're looking to build a TCP/IP server, Java may make it easy to do, but its lack of a select()-type call or asynchronous i/o means that Java today isn't going to give you nearly the best results.

    But, if you're looking to build a portable distributed application with graphics and interactivity beyond the web browser, with lots and lots of classes, many thousands of objects, tons of concurrent threads and a nearly transparent networking layer for distributed object calls, and you want to be able to leverage as much reliable, pre-written classes as possible, Java is just the thing.

  • Re:Java is plainly too slow. (Score:4)

    by Me2v ( 12239 ) on Sunday August 20, 2000 @10:54AM (#841519) Homepage
    I work in the industry, and currently code COBOL, Java, REXX, and Easel (does anyone remeber that piece of crap!!). I can say with authority and absolute confidence that a well coded application in C is lightyears faster than a well coded application written in Java. I attribute most of that to the JVM, though.

    I've seen 'real' applications written in Java. I've used Moneydance personally, and several custom apps we've designed at work, and a couple of shrinkwrap apps written in Java, both stand-alone and Web-based. For the most part, they perform very well. Java does indeed rock as a programming language. That, however, is a seperate issue from it's execution speed, and it's speed (or lack thereof) cannot be attributed to the language as a whole, but rather to the implementation of the JVM. A good JVM and/or JIT greatly enhances the Java experience.

    People who say that Java is slow are correct, for the most part. Even with the best JVM, Java cannot approach the speeds of a well-designed native-code application. This does not mean that Java is a bad programming language, or inappropriate for mission critical apps. We have several mission critical apps written in Java. They run well, and are stable. The loss of speed in the application, though, was not great enough to outweigh the benefits of the cross-platform execution. We can design the app on AIX, OS/390, OS/2, Windows NT, or Windows 2000, and we can compile that app once, and then we can take that compiled app and run it on AIX, OS/2, Windwos NT, or Windows 2000, or OS/390. The simple fact of 'compile once, run anywhere' so far outweighs the speed loss that it's worth it.

    So, you are wrong when you say that "The very fact that someone claims that shows that they are not in the industry and have no idea what's going on in the Real World (tm)". I say that Java is slow, and I work in the "Real World (tm)". It's just that the slowness disadvantage is not near as important as the advantages.

  • 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.
  • I guess this something we should aspire to, eh?

    Good catch!

    However, to add some content, Borland demonstrated how much more efficient Java's garbage collection system is over native Windows memory management (i.e. New/Dispose) at the developer's conference this year.

    They ran a demo where the allocated and destroyed over a million objects. The Delphi version took several seconds to run. The Java one ran in under a second.

    They also demonstrated a few other "benchmarks". While Java didn't always win, it showed performance that was far better than I ever expected in many areas. As the VMs are optimized, I expect the performance gap to close even more.

    RD
  • If we consider release timeliness as a way to compare different Java base platforms the news for Sun is very poor.

    Order in which JDK 1.3 is/will be released for various platforms:

    • Windows (out now)
    • Linux (out now)
    • AIX (out now)
    • OS/390 (out now)
    • Solaris (real soon now)

    Has to be a tad embarrasing for Sun!

    --

  • Thoughts from a Java shop (Score:2)

    by Anonymous Coward
    I used to work for a Java shop, and, well, they were no fans of Linux. They tried Linux and found Linux unstable, and that Linux had less-than-ideal performance.

    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

  • Re:Java is plainly too slow. (Score:5)

    by macpeep ( 36699 ) on Sunday August 20, 2000 @10:01AM (#841529)
    Java is plainly too slow

    *yawn*

    Obviously it's fast enough for the couple hundred thousand or so (millions?) of Java coders and companies that use it every day in mission critical applications all over the world.

    Seriously, I doubt you have any real world experience with Java if that's still your take on it. Yeah, three years ago, it wasn't fast enough. Things have dramatically changed since then.

    Anyone can code a crappy app in C and say "woah! look, it sucks! it's slow!". That doesn't prove that C would be slow - it proves that the code sucks. In the same way, an amateur not knowing what he or she is doing with Java can see slow apps. If you know what you're doing, the situation is different.

    I don't know about the rest of you here but I'm getting very tired of the same old "Java is slow" and "I've never seen any real apps in Java" myths here on Slashdot. The very fact that someone claims that shows that they are not in the industry and have no idea what's going on in the Real World (tm).

  • I'm just in the process of writing a Swing app (JDK 1.3 / Sun). It runs nicely, the GUI's concept is simple to understand, so -- where's the problem? My story is as anecdotal as any, but what is so bad about Swing?

  • 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.

  • Let me see If I got this right...don't use Java (pure OO), use Pascal (Delphi by any other name...). And you're telling ME to grow up?

    Try going below to read some of the other, more well thought out comments before you spout idiotic nonsense.

    Would I use java to create a graphic-intensive, Windows only exe? No that's not what the tool is for. Would I use it to create a thread-safe, cross-platform networked servlet? Now your talking.

    About 10-15 years ago many people were saying the same thing about some upstart, slow, bloated language called C++. I guess we know what happened to that.

  • It also occurs to me that the only company which makes quality usable client side java apps is Oracle. Just about every single one of their client side apps is written in Java including the installer.
    Why isn't sun doing this stuff?

    A Dick and a Bush .. You know somebody's gonna get screwed.

  • 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.

  • Read last month's linux journal (Score:4)

    by Ars-Fartsica ( 166957 ) on Sunday August 20, 2000 @10:09AM (#841552)
    A fairly rigorous set of benchmarks was performed by Michael Hirsch in the August 2000 issue of Linux Journal.

    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.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close