Java Rocks On Linux 156
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."
Re:I *can not* stand this anymore. (Score:1)
Re:Java is plainly too slow. (Score:1)
Faster on linux? Maybe. (Score:1)
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.
Re:Java is plainly too slow. (Score:2)
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.
Re:Blackdown, ptreads, ... (Score:1)
Re:benchmarks "not dated" (Score:1)
Java for Linux is still far behind (Score:1)
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.
Re:Java is plainly too slow. (Score:1)
Like using stringbuffers instead of strings when doing lots of concatenation.
Too much java news! (Score:1)
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
Re:hardware time is cheaper than programmer time (Score:2)
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 [slashdot.org] in another thread -- many of the other replies in that thread are good as well. Have fun.
~wog
Size matters (Score:2)
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.
Re:Java is the epitome of lag (Score:1)
Re:Poorly written code == slow (Score:1)
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.
Re:Open Source Java? (Score:1)
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!
Re:Obviously, you didn't research your argument. (Score:2)
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.
Re:hardware time is cheaper than programmer time (Score:1)
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
Re:You Used The Wrong Tools For The Job (Score:2)
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.
Re:Java is plainly too slow. (Score:1)
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 [flipcode.com] on flipcode.com if you want to read about my progress.
Re:On Java's Slowness (Score:1)
Also, I disagree that the performance sucks.
There is NOTHING you can do in DELPHI... (Score:1)
- ... 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.
Re:Java is plainly too slow. (Score:1)
How does IBM's embedded Java VM on Linux compare? (Score:1)
Re:Java is plainly too slow. (Score:1)
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)
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.
Re:professional Java developer? (Score:1)
Re:Please, no more articles about benchmarks (Score:1)
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
Re:Obviously, you didn't research your argument. (Score:1)
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.
Re:So why no JVM in Mozilla? (Score:1)
_____
Re: (Score:2)
Re:You Used The Wrong Tools For The Job (Score:2)
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.
--
Blackdown, ptreads, ... (Score:2)
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
Re:Java strong at the server, weak at the client (Score:1)
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
Re:Java is plainly too slow. (Score:2)
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.
Re:Java strong at the server, weak at the client (Score:1)
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.
Re:Java is plainly too slow. (Score:1)
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)
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
Java Will Die... (Score:1)
...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".
Re:Java is plainly too slow. (Score:1)
Java is plainly too slow. (Score:1)
Re:Java is plainly too slow. (Score:4)
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.
Re:Poorly written code == slow (Score:1)
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.
Re:Java is plainly too slow. (Score:1)
Re:I give up. (Score:1)
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)
Fact is, you can't say Java is fast or slow, it depends a lot on the context.
Re:Java is plainly too slow. (Score:1)
Beside the point (Score:1)
Re:Java is plainly too slow. (Score:4)
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.
Re:I give up. (Score:2)
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
Re:So, about Java on LINUX... (Score:1)
Tom
Re:benchmarks "not dated" (Score:1)
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.
Re:Not surprising at all... (Score:1)
Re:Java is plainly too slow. (Score:1)
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?
Re:Poorly written code == slow (Score:1)
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
Re:I give up. (Score:1)
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
Re:Poorly written code == slow (Score:1)
I kicked that monkey's ass (Score:1)
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
Wheel mice in next update (Score:2)
Re:Read last month's linux journal (Score:1)
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)
Re:Java is plainly too slow. (Score:1)
Re:JDKs (Score:1)
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.
Because people cannot resist hype (Score:1)
It really goes to show how few coders really know that much about their tools and why they use them.
enough being said, /. is a strong pro-Java forum. (Score:1)
Please, no more articles about benchmarks (Score:2)
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
Java/Linux Milestone (Score:2)
Re:Because people cannot resist hype (Score:2)
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.
Re:Java Rocks on Linux? (Score:2)
Re:Read last month's linux journal (Score:4)
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)
The speedup is directly visible in apps that use GUI's - Swing in particular.
hardware time is cheaper than programmer time (Score:5)
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
Dumbass moderators, again (was Re:I give up.) (Score:2)
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.
Re:I give up. (Score:2)
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)
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.
Re:Read last month's linux journal (Score:2)
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)
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.
Re:Java is plainly too slow. (Score:2)
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.
Re:Because people cannot resist hype (Score:2)
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.
Re:Java is plainly too slow. (Score:2)
You Used The Wrong Tools For The Job (Score:3)
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
Not surprising at all... (Score:2)
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...
Re:Open Source Java? (Score:2)
Re:Open Source Java? (Score:2)
"What a waste it is to lose one's mind. Or not to have a mind is being very wasteful. How true that is"
Re:I give up. (Score:2)
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)
Last Modified: Sun, Aug 6, 2000 2:59:48 AM GMT
Re:Thoughts from a Java shop (Score:2)
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).
--jbRe:Read last month's linux journal (Score:3)
Funny, that's just what they say on JavaLobby about Slashdot
Open Source Java? (Score:3)
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.
Re:Because people cannot resist hype (Score:2)
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)
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.
Re:Thoughts from a Java shop (Score:2)
Re:An amazingly unfortunate typo (Score:2)
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
Java on Solaris, Windows and IBM (Score:2)
Order in which JDK 1.3 is/will be released for various platforms:
Has to be a tad embarrasing for Sun!
--
Thoughts from a Java shop (Score:2)
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)
*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).
Re:Java is plainly too slow. (Score:2)
In defense of Python and Perl (Score:2)
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.
Re:Java = No advanatge, Delphi for Linux = Rocks (Score:2)
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.
Re:Not surprising at all... (Score:2)
Why isn't sun doing this stuff?
A Dick and a Bush .. You know somebody's gonna get screwed.
Wahhhh! Sob WAAAAHHHH!! (Score:2)
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)
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.