Slashdot Mirror
Java Urban Performance Legends
An anonymous reader writes "Programmers agonize over whether to allocate on the stack or on the heap.
Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs."
And yes I haven't read the article because its slashdotted
Web site seems fine to me.....
Yeah, I do not think that IBM's websites could get Slashdotted. Article looked fine to me too, and loaded in a second or two.
Click here or here.
These java urban performance legends are rubbish - java is highly performant in a rural or urban setting.
but the main thing that frustrates me is the difficulty in storing primitives in sets or as keys for maps. I realise that there are libraries available such as pcj, but it's still annoying :)
Unpretentious Sydney reviews by unqualified Sydney reviewers
How much time have I spent with Electric Fence and valgrind finding memory leaks in my C programs? In Java, the auto garbage collection is as good as Perl's, without that tricky "unreadable code" problem ;). And I can always tune garbage collection performance by forcing a garbage collect when I know my app's got the time, like outside of a loop or before creating more objects in storage.
--
make install -not war
JVM memory allocation isn't "SLOW". It's just pleasantly unhurried.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Here or use the Firefox extension.
JVMs are surprisingly good at figuring out things that we used to assume only the developer could know.
:) ) they weren't. The performance of the language has greatly improved while the perception of language has remained the roughly same (at least amoung the general coding community).
Yes they are. Now. 10 years ago when Java applets were being embedded in webpages (to show rippling water below a logo
Just goes to show that even if you have a great technical product you'll still need the marketdriods. Unfortunately.
http://twitter.com/onion2k
These articles keep popping up flatly stating that Java's slowness is a myth. But, no matter how many times you say it is a myth and how hard you try to create a new perception, the FACT is that people's real-world experience, no matter how anecdotal, consistently demonstrates that Java is MASSIVELY slow than similar apps in C or C++.
Java is slower. Don't even get me started on C#.
The memory allocation management routines are normally running when the JVM thinks it's best, but as a programmer it is usually possible to predict the best time when to actually take care of the housekeeping. Even if the memory management cleanup takes the same time in both cases Java has a tendency to issue them in the middle of everything. So if I as a programmer does the garbage collection at the end of a displayed page and Java does it uncontrollable in the middle of the page the latter case is more annoying to the user.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
How many JVMs can you afford to run on your system for different apps, and how can you make sure they are all the right size, the garbage collectors are in an appropriate mode that can keep up with generated garbage, etc. I can run lots of native apps, which in many cases have no need for a significant heap like Java brings into the picture in far less space than a single JVM. A JVM runs much heavier on the system, and when I run Netbeans, it is continuously on the verge of eating my 1.2 GB powerbook alive, in fact I have to frequently restart Netbeans to get memory back. It has a long way to go in real practical terms even if they have theoretical solutions to some of the problems. I am porting my server software away from Java for the same reasons. This is JDK 1.4, and I am about to try it on 1.5, but I don't think there is that much difference.
The article explains what in theory can be done by smart VMs. But all the examples in the article aren't tested in practise. Maybe the escape analysis the author describes works as advertised. But without actually testing and analysing real code produced and without actual benchmarks the article doesn't proof a thing. One thing the author seems to forget is that you would at least need a fallback mechanism when a method is overridden in a subclass (all the examples don't use final classes or methods). A subclass could override one of the get() methods and put some values in a cache (to keep some statistics for example). In such a case the VM has to detect such a case and "de-optimise" the inlinded code again. Maybe this can be done without too much overhead. But only really measuring these things in real world applications will tell.
I would love to have pointers to real data though.
Network-bound java servlet applications may perform better in built up areas, due to the higher bandwidth of urban ADSL connections.
This article is actually debunking some people's reasons why Java has poor performance. It does little to debunk my actual real world experience that it *is* slow. I'm glad to see that performance has increased alot, but I remember some all (well 90% or something) Java applications, like the original JBuilder, that made me want to claw my eyeballs out when using them. Those apps and other early apps are where Java's performance issues really took hold in many people's psyche.
You so called counter argument is 6 years old... a lot of it weren't true to begin with, and a lot of things have happened since then.
In the end though, the MOST important thing is that these days, processor cycles are cheap. Programmer cycles are expensive. Therefore it makes sense to sacrifice a little bit of program performance to get more productive programmers.
Being bitter is drinking poison and hoping someone else will die
the people who keep telling me allocation in Java is slow (much slower than 10 instructions) are generally experienced Java programmers. I use Ocaml, so I'm quite aware of how fast a generational garbage collector can be (btw, on the x86 in Ocaml, allocations are only 5 simple instructions). But from all first hand reports I've heard, Java allocation is still slow. It may be faster than C++, but it's still slow.
The best way to think of it is: Java = C (the cleanest of C!) & Java extension for portability and interoperability etc. SADLY most novices just dont get this. AND Java garbage collection is now next generation and way ahead of anything else out there. It's alomost flawless.
Programmer cycles are expensive.
Not if you're counting in rupees.
I've had many professors say that Java is nowhere near as slow as it used to be, and that it was just a myth now that it is that much slower the C or another language that doesn't rely on VMs. In most applications, I guess it's actually equal enough to C to be considered as an alternative. Although it doesn't have anywhere near the rich number of libraries C/C++ works with (I'd like to see someone make a cutting edge game in Java).
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
While he's at it, could he also address the myths that Lisp and Smalltalk are slow too? Because they're not, they're pretty fast (though not as fast as C) and they offer vastly improved programming environments which leads to vastly better development time, which C can never hope to achieve.
First post here from my Java workstation. Take that!
what if java's allocation may be non-slow? What counts is that java applets and AWT/Swing applications were slow in the late 90's, and by damn-it, thats what we slashdotters like to base our opinions of java on!
1. Make it work.
2. Make it work well.
3. Make it work fast
And #3 is the most interesting... how fast is fast? In an absolute sense, sure, C/C++ will always be faster. But does the end user notice this in a webapp? NO!
I have a p3 450mhz box running Tomcat/MySql. It serves my local applications fast enough. The server can render the page much more quickly than my browser (on a p4 1.5ghz box) can render it. As a webapp, java on an old machine is plenty fast.
Java as a desktop GUI is an altogether different story, but I'm not using java on the desktop. This point is moot to me.
"Fast enough" to not be noticeable. That is the secret of #3. In a webapp, this is easily achieved in java.
The copying collector sounds really fast indeed, but I can immediately see two problems:
The first one is the need for a huge amount of memory. It would seem that the optimal way of dealing with this is restricting the amount of memory available to the application, otherwise any app can grow to the maximum size allowed by the VM, whether it needs it or not. But this sounds rather crappy to me, now every developer needs to figure out an right limit for the application.
The second is that performance is going to suck when garbage collection is performed. The slowdown could be a lot larger than a single execution of malloc/free, especially if virtual memory is taken into account. The unused half of the memory will often be quickly moved to swap by the VM, especially when the process grows to sizes in the order of hundreds of MB. Then GC will force bringing all that back to RAM, while possibly swapping the previously used half to disk. Exactly the same situation as what's described with heap allocation, but a whole lot worse.
It sounds to me that even if malloc is slower, it's a lot less inconvenient in applications like games, where something that is always slow can be taken into account, but where a sudden run of the GC could be really inconvenient.
But this is not my area of experience, so it's just what came to mind. Can anybody confirm or refute these suspicions?
http://www.agency9.com/
No matter what the theory says, your average Java application could be written to be more resource efficient, overall, in C/C++. That's the experience. (So Java's either inherently slower, or your average Java programmer is just really really bad at writing efficient algorithms.) Maybe Java will some day meet the assembly-level languages. I do doubt it, but I'll permit the possibility.
What I'm more interested in is porting this supposed efficiency to C/C++, if it's so useful. First, can we demonstrate that the model doesn't beget yet more allocation (which could shoot it in the foot)? It doesn't seem to at first glance. So, what's stopping a C++ coder from calling a monstrous malloc(), then using their own memory management routines on their userspace heap? Nothing at all. That's basically what Java has to do anyway (well, it probably uses brk()...)
Here is a paper (PostScript) from 1987 on the topic of GC being faster than manual allocation.
The author went on to make a very fast GC that set speed records.
If you are looking for factual arguments, with performance measurements and so on, just look at his work over the last few decades -- you'll see he did a lot of work in these very practical areas.
When you see how productive guys like him can be, it makes me wish that some people would just stay alive, and keep working, for a few hundred years more, instead of our typical mortal lifespans.
http://www.thebricktestament.com/the_law/when_to_
This is the funniest post I have ever seen on Slashdot!
Think about the article and the n look at the post! Mod parent way up!
It's not the speed that is an issue, so much as the inability of java to function well outside of number crunching. Its graphical toolkits are crap, slow, non cross platform and ugly. As well as this it can't be used efficiently for 3d, sure there's java 3d, a terrible kludgy hack on top of opengl. If i could use java efficiently for programming graphical applications then i might consider it.
java's microbenchmarks prove where it doesn't have problems.
the java platform's mantra is "create and use objects". when you compare java to languages that allow objects, but are not heavily object oriented in terms of their supporting framework and libraries, then what you are seeing is the expense of the OO paradigm.
Then use Delphi, or better yet, C#. (or even Python and a few other choices)
Faster productivity, less bugs, no ram guzzling 5 minute startup. Java isn't the only language that reduces development time, it's just the only one (besides VB) that makes you sacrifice big things to get it.
I thought this was about the seattle music scene...
Seriously shouldn't it be "Java Performance Urban Legends"
Perhaps the web server is written in Java?
WTF??? You claim that since Java is fast enough for you, running a webapp, on older hardware, running locally, for a single user, it must be fast enough for everyone? Suppose, just for the sake of argument, that there are more than one users! Suppose you are CNN.com and that webapp has to serve 2 or 3,000 users per second. Is Java fast enough then? Is it faster than C++? Is it faster than C? Are you retarded??
get educated
A *good* C++ programmer will probably write code that outperforms the equivalent in Java. A *good* C+ programmer will remember to deallocate all of his objects to prevent memory leaks. A *good* C++ programmer will copy his strings correctly to prevent buffer overflow exploits.
If you have been involved in developmnent for any reasonable amount of time or worked on projects of reasonable size, you know that *good* programmers are hard to come by. When you add the real world to the picture you find that simple things like garbage collection and a virtual machine can make a mediocre java programmer outperform a mediocre C++ programmer.
If schools actually learned to produce good programmers, and HR departments learned how to identify them, and job interviews verified them, we wouldn't be having this discussion.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Alternative, the author is an idiot savant that never overwrite memory in C, but still isn't smart enough to realize why it happens to other programmers (and realize that it slows development down, not makes it impossible, which his argument about writing OS kernels in C seems to assume).
Karma: Excellent (My Karma? I wish...:-( )
Java and C# programs tend to slow down for another reason, the programmers. I have seen a lot of programmers who throw and catch exceptions like candies, lock out entire functions as critical sections and what not. Although C# and Java does make programming easier by hiding details, they make it also make easier to do things that may slow down program execution.
Programmer cycles are expensive.
Indeed. It might be worth (pardon my pun) reiterating what those cycles really are, in regard to application performance.
In all languages I know of, you get some library functions ready-made, and you need to code some stuff yourself.
Most performance problems occur in the code you made yourself.
In my experience, you get most bang for buck when you are able to efficiently allocate your programmer time to a) program a functionally complete draft version, b) optimize those parts which need optimization and c) maintain the program, in a manner which is BALANCED, but biased towards maintenance.
De facto, you get better balance between those things, and most bang for buck, using languages such as Java, as opposed to languages such as C++, because (say) Java offers a pretty coherent conceptual framework (class libraries) for creating your draft in a maintainable way, provides default access to excellent non-invasive performance measurement tools such as YourKit and JProfiler which let you objectively find out where you need to do performance work.
This means you can do only the optimization work that is necessary, and create optimized packages which extend the default class library interfaces which means that generally maintenance programmers don't have to put nearly as much work into figuring out how the optimizations affect the draft work.
It's not perfect, but it gets you more bang for buck, which is what matters to you when you manage resources.
Not the default developer perspective, I know.
In most cases it's other factors contributing to performance problems, mostly i/o. If it's memory, you buy extra memory. If it's cpu, you buy faster cpu's. If you can. If you can't then you have a problem if you go to multi-core cpu's. Multi-core cpu's are the Achille's heel of garbage collection since it requires a "stop the world" synchronization to safely avoid race conditions in determinine what memory is referenced or not. "Stop the world" is hugely expensive on multi-cores. There are specialized multi-core cpu's for java out there but they tend to run the jvm's on single cores with relatively few hardware threads to avoid this problem.
*by Anonymous Coward on Sunday October 09, @09:42AM (#13750252)
Programmer cycles are expensive.
Not if you're counting in rupees.*
development time always costs.. no matter how cheap your coder is, you could still make more bucks if you had the product in hand faster.
currently I'm doing symbian c++.. and I'd much rather use java, I'd write more reliable code and do it faster as well(I'm not a superman and we all _know_ that everyone does mistakes sometimes - and quite frankly symbian c++ just makes it more probable that I'll end up doing one or two mistakes along the way) - if it were possible in any way, sadly, the product is not possible to be coded in java on the target platforms - the j2me vm's are too restrictive.
world was created 5 seconds before this post as it is.
Really? Can provide a few REAL world examples? Can you name one? Personally, I'm running Azureus and Netbeans right now, and they're not perceptably different from C++ desktop applications like KDevelop or OpenOffice.
The article's main point is that Java's memory allocation is faster than malloc, and it's garbage collection is better than cumulative free's.
However, thats not the problem. All memory in a Java program has to be allocated dynamically. Other languages offer static memory alternatives. Static memory use will be more efficient in many cases.
The my language is faster than yours argument is inherently stupid. There is no "best" language. You need to use the right tool for the right job.
--Barry
Rather than promoting your prejudice, why not RTFA, or this 19-year-old paper.
I'll await your learned rebuttal.
it would be interesting to see what is the overhead of the "Object" for different JDKs on 32/64 bits implementation? If class {int x,y;} takes 128 bytes, why would I care about speed of the memory allocation? They also mention thread specific allocators which are nice, but only if your program is nowhere close to max memory.
Simply put there may be fast efficient tiny java programs out there but I don't see them. I don't really care about how garbage is collected. All I care is that a simple editor gobbles up memory like it was some kind of FPS. Sure I love the fact that I can use the same editor with the same extensions (to a point) on my home linux machines and work evil OS machines BUT it comes at a price and that is a lot of memory.
Perhaps Sun has indeed improved java massivly over those horribly slow and crashing java applets we had a few years ago that were so going to take over the net by storm. Perhaps all the problems are just due to certain public java programs being badly written.
It doesn't matter, java is slow, c is fast. Instead of having written this article perhaps the author should have examined some common java memory hog programs and analyzed wether the fault lies with java OR the coding in question OR and this is an option few consider, that JAVA apps and C apps are often compared like apple and oranges. Azureus vs Bittorrent (a tiny and far simpler app) Eclipse vs VI etc etc.
A lot of languages deal with mis-reprensatation. I don't exactly feel sorry for the bad rep that java has as many java fanboys happily spread un-truths themselves. Like java vs PHP vs ASP for web development. Judging from my own experiences all this is just one giant "Your mom is so fat ...." competition.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Are you kidding? You're saying that Azureus, a BitTorrent client, is "not perceptably different from" a multi-language graphical IDE or a full blown office productivity suite??? From your statement it sounds like Java, or at least Azureus, is pathetically slow compare to C++ desktop applications.
Why don't you try comparing two BitTorrent clients instead? Try comparing Azureus with KTorrent, a C++ BitTorrent client. You will find that KTorrent is orders of magnitude faster and also uses a tiny fraction of the memory that Azureus uses.
Apples to apples, Java is SLOOOOWWWWW...
I think automatic garbage collection is great, but _my_ problems with Java's memory allocator have little to do with performance. Rather, it sucks so hard at dealing with out-of-memory conditions.
Why would you ever run out of memory? If you're on a microcomputer, you tend to have an arbitrary limit anyway. The JDK default is 64MB max heap. This is to prevent runaways, but setting the heap size to some arbitrarily high number has really awful performance characteristics -- god help you if you set the number higher than the amount of RAM you have available, or applications that want to share the machine. There's a whole other rant about how stupid automatic garbage collection is on a timeshared environment (like a server), but it's not the point I want to make.
The point I want to make: since Java is supposed to run everywhere, you really can find environments where you only have 1 or 2MB of heap to play with. Having constrained resources is nothing new to programmers, they've been dealing with it forever. But Java's allocator combined with constrained resources leaves you with very little wiggle room.
If you've ever developed a Java applicatoin that manages an in-core cache you might have experienced how fucked you are when you get around to the logic of cache expiration. Ideally you can keep cache forever, as long as a) you know it's not stale, and b) you don't need the memory for something better. A is not a problem in Java, but setting up a system to facilitate B is actually really hard. In C/C++ you can wrap malloc() so that if it fails, you can start dumping cache until it succeeds. The solution is elegant, dare I say beautiful.
In Java this is totally impossible. When you run out of memory the garbage collector is tripped, and if it can't free anything up it generates an OOM exception. You can't realistically catch these exceptions -- they can bubble up from anywhere at any time. The only place you can catch them is at the top of your program loop and the only good it does there is let you say "OUT OF MEMORY" in a user friendly way before exiting the application -- assuming you have the resources left to even say that of course.
So how does this effect your cache model? Well, you end up having to guess at how much cache to maintain. Guess too high and your application breaks when it's run in a low memory environment. Guess too low and you're not caching enough, the user experience suffers when it has no reason to. The above scenario is just one example.
Essentially, the problem is one of prioritized memory. Java gives you no usable way of saying memory allocated for purpose X is fine as long as purpose Y is not short. Designers and apologists can make excuses for why Java doesn't support this and maybe provide a good reason, but those reasons hardly qualify Java as a general purpose programming language.
Goto also.
Sun is introducing shared memory in the new VM that should alleviate this somewhat.
The idea is that the majority of the "fatness" comes from the libaries. If you only have to load the core libraries once, and each VM can use them then additional VMs won't add so much overhead.
If this works, I'm wondering, will we get side-effects from the over-abuse of static member variables.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Anonymous kettle Coward, learn to capitalize and punctuate before spewing garbage about "getting educated" and illiteracy.
--
make install -not war
C# and VB.NET are almost identical in features. What do you "sacrifice" that is really important? The .NET framework is still there. C# is just java like syntax for .NET. Its not 100% better as its billed by microsoft and consultants. I agree vb6 sucked.
.NET app startup time is slower than running a program written in another language as well. Try running the ati control panel (.net version). Now that is slow. Limewire loads faster and its a java app.
The java vm startup time is a problem for client apps, but server side its not a big deal. Running tomcat with servlets, jsp and the like is very fast.
MidnightBSD: The BSD for Everyone
The typical home machine these days is still sub-ghz, and Java performs so poorly as to be unusable on such machines.
I am trolling
I haven't done anything with java in the last 5 years.
...BY HAND!! IT WILL NOT COMPILE ELSEWAY.
*everybody.screem("w00t!");*
I can understand the discussion about memory allocation is legitimate.
*everybody.agree();*
Now, saying this would not be the case anymore, so hence java is fast now, would be false.
*everybody.status = iritated;*
Writing jevecode does make yu handle a lot of errors...
*everybody.ask("is this not good?");*
*some.ask("is this not good?");*
Maybe there is a loss of speed for handling all those errors as well.
*FirstHalfOfCoders.grab(stone);*
C coders don't check for every possible error.
*SecondHalfOfCoders.grab(stone);*
Maybe, sometimes, it is ok for a programmer, if from that code, there could
be errors. While on the other side you buy speed with insecurity.
*FirstHalfOfCoders.throw(stone);*
*SecondHalfOfCoders.throw(stone);*
*me.troll();*
AND BY THE WAY; I LOVE THE "GOTO" STATEMENT!
*me.run(away);*
Bjarne Stroustrup : why so many people use "C++" just as "C" ?
Dennis Ritchie : because you named the language "C++", not "++C"
I ran a test last year doing simple arithmetic comparisons between Java and C++.
Java won. The Just-In-Time Compiler makes Java incredibly fast. Java seems slow not because it is, but because a lot of Java programmers are just downright lazy and refuse to code efficiently.
I have been doing Java programming for several years now and ported many C/C++ applications to Java, mostly server side apps and I'd say roughly 85% of the time the Java apps outperformed the originals, sometimes by an order of magnitude. Now these were more redesigns than straight ports and the performance gains were not because Java was any better from a performance standpoint, but because design is more of a factor in speed than the language used, especially for larger applications. Usually when I find big performance hurdles that are hard for me to overcome, I find I would have same issues in most languages, so finding a better design is usually the solution. If you are writing small - medium apps or mostly GUI apps then I might have reservations about Java, but for larger apps Java is a good choice.
Garbage collection is generally more efficient, byte for byte allocated, than malloc.
The problem is that Java programmers and Java libraries tend to be written in such a way that they do a lot more memory allocation, just because it's so easy to do. The quality of Java code in general is not very impressive (and this include Sun's own libraries). And Java itself makes writing efficient code harder than it needs to be.
So, people can write highly efficient code in garbage collected languages, and even in Java. But Java programmers generally don't bother, and that's the reason why Java has such a bad reputation, and it deserves it.
The typical home machine these days is still sub-ghz, and Java performs so poorly as to be unusable on such machines.
A typical mobile phone is sub-ghz too, and there is plenty of J2ME software running on them...
Java rocks on limited devices AND as server software. It is only on the desktop it isn't a big hit. Yet.
Being bitter is drinking poison and hoping someone else will die
did you read *either* of the articles?
see http://shootout.alioth.debian.org/benchmark.php?te st=all&lang=all&sort=fullcpu
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
it's significantly better.
if you RTFA you'd get some ideas as to why. perl's garbage collector is very, very stupid by comparison.
I disagree.
I've just built an order taking system Java/SWing for laptops for trade-show personnel to take orders in real time with 1000 listed products. I developed the system on a PII-600 (a nearly 6yo HP Omnibook 6000) to deploy on something equal to or better. It's almost indistinguishable from a C++/MFC app I might have authored in my youth.
I think there's something to be said for bloated frameworks (cough - weblogix) but Java itself is not overly handicapped wrt performance.
I've never believed that Java's garbage collection is the root cause for its slowness. I do believe that Java's GC is the cause for its random (and more notably, its inconveniently timed) stutters.
I think the more general Java slowness comes from the obfuscation of efficiency. In C for instance, ugly code correlated with inefficient code. This is no longer the case for object-oriented programming in general, and it is possibly worst correlated in Java.
The example in the article provides a starting point for what I'm saying. It's based on the algorithm for a point in some Cartesian graphics system:
The Component.getDistanceFrom() algorithm is considered "good OO style." By using bad style, though, you can break the pretty encapsulation -- and make "bad OO style" -- but get a performance gain:
Both code blocks require the math (two subtracts, two multiplies, an add, and a square root) but the original block (unoptimized) also requires the allocation of the Point object and the two memory copies to store the (x,y) location.
This is a trivial example, but my point is that in a complex Java project, readable and elegant code bears no correlation to fast and efficient code. I believe this is why Java is slow.
--- Jason Olshefsky
Karma: Poser (mostly affected by adding this line long after everyone else did)
Look at any of the BSDs. There's 3 complete unix operating systems, kernel and userland, all in C. And yet, somehow, memory leaks are simply not an issue. Sure, they happen once in a while, but not often enough to be a problem. Yeah, memory leaks abound in poorly written, buggy piles of crap like mozilla, but that's my point. If you have problems with memory leaks, then you are the problem, not C.
The typical home machine is more than 5 years old (or a Mac)? I doubt it.
Firefox even has its own garbage collection in the Javascript interpretation, but it's memory performance is orders of magnitude better than Java-based applications including NetBeans.
It depends on what kind of software you're developing. If it's an inhouse business or vertical enterprise application, you're right. If it's an operating system, RDBMS, video game, or office productivity suite, every bit of performance matters a lot.
So you're saying you dont care about how slow the client runs? What a great argument...
Unfortunately, programs such as Azureus, which run piggishly slow on a 1.2GHz laptop do nothing to dispell these 'performance myths'.
C doesn't program itself. These "language in a vacuum" arguments are specious, nonconstructive navelgazing.
--
make install -not war
The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call (Detlefs, et. al.; see Resources).
Wow, that's really shocking. Until you actually look at the Detlef paper and realize that it was published in 1994, 11 years ago!! Who knows, maybe things have improved a bit in 11 years. The author certainly thinks Java is getting better; maybe it's possible that C/C++ compilers have improved as well.
Here's a link in case you ever get the urge to write some Java code.
So, the JVM allocation works, and there's no performance bottleneck there. But where is it? Why is Java still so painfully slow?
Java used anywhere, from webservers to full client apps just feels and even *looks* slow! Stop coming up with pointless articles. Find the problem and fix it.
Just because your voice reaches halfway around the world doesn't mean you are wiser than when it reached only to the end
Five minutes startup times is also a myth. Most small to medium size Java application I have start in under a minute. Of course the more dependencies and the larger the application the more time it will take. I suppose we could compare this to you average game, written in C/C++, which can take over two minutes before you are ready to go.
For an enterprise application, running as a server, start-up time is not really an issue. What does matter is ho well it does once it is running.
Jumpstart the tartan drive.
Sure. I also ran a test last year doing simple arithmetic comparisons between Java and C++.
Guess what, C++ won. There goes your argument.
Nevermind the fact that what you did is compare one JVM to one compiler generated binary...
Just because your voice reaches halfway around the world doesn't mean you are wiser than when it reached only to the end
Have you read the article you link against? You don't know a lot about compiler design, do you? Well, don't feel bad, you're not alone. The author of your article does not seem to know a lot about compilers either!
Some comments:
Zero time allocation? This may be true only if you use these values inside the same method or pass them exactly one method call upwards. If you pass them further, you get O(n) complexity for copying the values on the stack. Passing them m+1 methods upwards from allocation point, gives you O(m*n) copy time. Against O(n) allocation time for objects on the heap.
Yes, quite a lot of code, indeed. But only because you don't have the slightest clue about compilers!
Line (1) Why is your method returning a "destinationClass"?? A dynamic cast check has to return either true or false, but certainly not a class.
Line (4) Determining the cast target during run-time? Are you nuts?! This happens during compile time! Or since when can the static type of a variable change during run-time??
Line (7) Adjusted? Adjusted for what?? There is absolutely no need for "adding" an "offset". Why would you want to do this? The ancestors of a class in the class hierarchy are fixed at compile time, i.e. if you have a field a in class A and fields a and b in class B which inherits from class A, then field a in class A has index 0, fields a and b in class B have index 1 and 2. Example:
The indices are known at compile-time!! A cast only has to return yes or no, valid or invalid.
Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
What is the point of garbage collection in a JVM when it takes a few hundred megs just to start up? (*nix)
The only people saying that processor cycles and ram is cheap are those that can afford a 4gig system with a quad opteron and they run a command line system.
The rest of us live in a reality where software IS poorly written and sucks cpu and ram in a bad way. X, Mozilla, gaim, apcupsd, artsd, it isn't at all unusual to have all of these running at the same time.
root 21303 0.8 15.1 294828 155172 ? SL Sep01 462:11 X
root 8404 0.1 0.0 33940 148 ? Rsl Aug29 64:42 apcupsd
david 21395 0.0 0.7 135776 7224 ? S Sep01 16:05 artsd
david 2615 0.7 26.2 487972 268656 ? S Sep20 213:12 gaim
david 948 0.3 13.8 427656 141404 ? Sl Oct07 11:35 seamonkey
If I start up a jvm, bang, another hundred megs and tons of cpu gone.
david 7023 0.0 0.1 4776 1088 ? S 11:37 0:00 limewire
david 7024 24.2 11.0 1435432 112584 ? Sl 11:37 0:10 java -cp
(process name edited for readability)
In all the time that I have used java in the last ten years, java on *nix has always been a beast.
Maybe I'm wrong but I wasn't under the impression that software is designed to only run one program at a time on a computer.
Garbage collection should take second place to garbage creation...
One approach to speeding up Java applications involves drawing a prudent line between what will be done in Java vs. native code. Java purists may claim that anything less than 100% pure Java is evil, and there are trade-offs, particularly in the area of security. If you're pragmatic, and use the right tool for the right job, don't be afraid to use native libraries where appropriate. You don't have to go all or nothing.
For example, to speed up Java apps running on the client (not in a browser, full applications), use Eclipse's SWT. SWT is a UI toolkit that (mostly) uses the underlying Windowing system's widgets, rather than trying to draw everything in Java. As you might expect, this leads to some nice behavior from a performance standpoint. For example, try resizing windows in Eclipse on Windows XP. You'll notice very smooth redraws of the underlying components while the window resizes, just like a C++ app. Now try the same thing in Netbeans.
Similar solutions exist for accessing OpenGL natively, rather than using a more "Java heavy" library like "Java 3d."
I'm willing to believe that Java allocation/deallocation, in bulk, is better than C++ when amortized over the course of an entire application. The problem is the lack of control; while this is no longer an issue in most parts of the development world, for real-time applications -- and gaming in particular -- performance has to be good from start to finish; taking a time hit to free up memory is fine when you do it yourself at the end of a level, but not so cheerful when it happens automatically in the middle of your boss fight. This isn't a fatal flaw (my current side programming project is a Java-based game), but it's an inherent aspect of the language that severely hampers its applicability to some programming jobs.
Or, in most cases, wasn't top of the range when it was bought.
I am trolling
I have never felt the last bit of anxiety when choosing to "allocate" an object on the stack. I do not even call this an allocation, I just use a local variable that happens to be an object.
I only allocate an object on the heap when I know this object needs to be exported from the function -- which is something I'd better be aware of by design.
Stack-allocation is an easy, default, way of life in C++. It is even a key idiom for managing non-memory resources (RAII).
When programming in C or Java, what makes me agonize is to manually ensure that (non-memory) resources are released properly and in a timely fashin (files, locks, communication ports, etc). try...finally blocks, anyone ?
Agreed. There are few things more fustrating than forced twiddle thumb time because an app is loading. Sure, for most apps it's probably only 10-20 seconds of idle time for the worker, but that can add up over the day. One must consider the full ramifications of "Sacrificed Processer Cycles". If it's in house, it's easy, who gets payed more, programer or end user. If, however, you are doing a comercial app, you are wasting your constomers time. Do it enough and they will go to your competitor.
While I'm sure you can point to a Java program which takes 5 minutes to start, these are the exception in the Java world, not the rule. In fact, the JVM takes seconds (a small number of seconds, less than 5) on all of my systems, including P3's as well as older AMD's. It takes less than 2s on my Athlon 4800+. I can go from Tomcat not running to it being completely started up and serving requests in 4s on my PC, and 11s on my older G5. My IDE, which is extremely feature-rich, takes ~90s to get to where I can start typing code from a completely cold start, in a middling (30K LOC) project. That includes a ton of lib caching and such, so that it can do incremental compilation in real time. It takes 16s to restart once that caching is done.
.Net in memory for your C# program, and that's no small chunk of RAM. The first time you start up a .Net app of any size you're going to be waiting for it to draw for just as long. And it's no better for scripts, just how fast does Mono start up anyway?
As far as guzzling RAM goes, all programs these days guzzle RAM, and they're right to do so, because RAM is cheap. This is not unique to Java, the IDE I mentioned uses 56M once it's really going, surely not an unreasonable amount of memory for such a complex app. Java is still not the best choice for small scripts, Python would be better if your program is going to be mostly startup/shutdown time. C# is no better than Java though. Don't forget you need most of
What are these "big things"? Inline assembly blocks? Besides, why should they use Delphi or C# rather than Java, if they're all the same to you?
A typical mobile phone is sub-ghz too, and there is plenty of J2ME software running on them...
Java rocks on limited devices AND as server software. It is only on the desktop it isn't a big hit. Yet.
Ha! That's a good one. I work with mobile phones, though I personally don't use J2ME. All the programmers I work with do though (the carrier chooses). J2ME really sucks.
The J2ME spec has a lot of fuzzy places and "MAY"s. You will find the full spectrum of possibilities in such places. There are also many imlpementations that blatently fail to meet the spec. (I've heard that boolean operators *sometimes* short-circuit, but I'm not sure I believe that.)
Fixed point math is common for these small systems. In Java, you end up looking like Lisp. FP.sqrt(FP.add(FP.mul(a,a),FP.mul(b,b))); Yuck. In C++, you look like C++. sqrt(a*a+b*b);
Then there's the jar size limits. Some phones only give you 64k to work with. And on top of that, each new class and function adds to the size of your app. So if you want to do some nice modular OO design, forget it. With C++, no problem. There are no size limits (aside from usable memory) and extra classes/functions are nearly free. Again, in C++ you can reuse loops and wrapper code to shrink code size, passing in a function pointer for the inner part. In Java? The extra overhead for the class you'd need to work that way cancel out the benefit.
Garbage collectors typically used in J2ME are way behind server and client versions. And when they don't work well enough automatically, system.gc() might force a garbage collection. Maybe, if you're lucky and the manufacturer felt like implementing it.
J2ME phones are almost universally one notch slower than the BREW equivalent. Some of the Samsung phones have poor performance under BREW, but are simple dreadful with J2ME. It's the difference between getting 4-5 frames per second and getting 1-2 seconds per frame. And if you're doing funky stuff with bitmaps that the phone has a slow implementation for, in C++ you can walk around the implementation and do it yourself. In Java, you're screwed.
J2ME is a joke.
C# is just java like syntax for .NET.
.NET 2.0 is superior to Java 5's.
"Too much syntactic sugar leads to code cavities", but C# has a LOT of syntactic niceties that Java doesn't. (Operator Overloading being a prime example.) Some benefits go beyond mere syntax, for instance generics support in
Garbage collection is nice. It does its job and it does that job well.
But garbage collection only helps you manage one sort of resource. In C++, the RAII techniques that help you manage memory are good for every resource, from file handlers to database connections. Resource management in Java is not so nice. Often it is quite a hassle.
Also, if you really want the benefit of garbage collection in C++, simply compile your program using something like the Boehm Garbage Collector.
Might help if I spelled shit right.
Got Code?
Single inheritance is the one that is simple to implement. As an application programmer I want the one that is simple to use and that means not having to program around language limitations.
all the energy released by a an article that is conceptually flawed... it is supposed to be an engineering discipline. engineering disciplines are about using the mathematical models to make appropriate decisions trading off different abilities to get the best "fit" for the desired result. verticle and horizontal understanding of technologies, their uses, strengths, weaknesses, & costs can be a complicated. as shown by the replys to this article. too bad such energy isn't funnelled into create better usable models about how to make technology choices for the job at hand...
Which is the point.
Systems programmers write systems code. There is no one size fits all. There is no silver bullet. Comparing out-of-the-box C/C++ to out-of-the-box Java is a non-starter in my opinion because I've never used out-of-the-box C/C++ for large scale performance applications. What Google did in writing custom systems software is something that cannot happen with Java and is the accepted practice for C/C++.
Java programmers write applications in a "one-size-fits-all" performance environment. Comparing Java to C/C++ is like comparing apples to oranges.
Serious C/C++ systems programmers write their own malloc and systems software.
I'm not a developer, but I will choose a natively compiled program over a java program every time. I want my computer to respond as fast as possible every time and there is no comparison.
//My response to the Java bashers //thank you and have a nice day
benderResponse.bite(ass, shiny, metal);
Everything I need to know I learned by killing smart people and eating their brains.
Might also help if you kept your banal, "me too!" comments from contributing to the low signal-to-noise ratio. Say someting useful instead of trying to impress some anonymous strangers or making yourself feel better by receiving a "Funny" mod.
why run from Vincenzo?
VB.Net complies to the same code has C# if you turn on remove overflow checking and options strick. So how can you lump VB into a differenct category than C#?
You do realize that a checkers game written in Java running on a J2ME-enabled cell phone doesn't compare to any significant client application, correct?
Don't forget that John Carmack published an article discussing his dislike of J2ME.
Cyric Zndovzny at your service.
I thought Java was our savior, to lead us against the scourge that is Microsoft. Ha! Let's replace one bloated and buggy piece of software with one equally bloated and albeit less buggy piece of software. Slow, slow, slow. It started off as any day now you'll see Java take off to It's not your father's Java anymore. It still sucks. It's way too complicated. I'd use it before C# or VB or .NET anyday. I was far more productive with PHP and MySQL in a few days than I was with Java. Of course, I already knew Perl. Python looks even more promising. C++ has a steep learning curve too, but it's a real language and worth the effort. Java, is it a desert topping or a floor wax? It's both!
Fuck Java. I've said it before and I'll say it again. Java is only good for keeping programmers employed at companies who bought into the Java hype. And who are loathe to admit they already spent too much money. It could be worse though. They could be using Oracle, a great system, that is too complicated to make effective use of.
I've come to terms now with Java's place in the annals of programming.
It's a political language. It's a language you learn to get a job.
It does not appear to be a language you should write any commercial applications in.
I'm going to get hated for this but that's how I feel. I've never seen a Java app that wasn't really bloated and slow.
Puzzle Pirates is a prime example. If that application had been written in something like C/C++, it would run a hundred times faster. It's dog slow and laggy no matter what system you have. I just built a new PC with the fastest processor, best graphics card, hooked up on a full T1 to the net with no other traffic on the pipe and still YPP runs like a dog.
I have yet to see any impressive commercial Java application. I'm sure there are some out there, but on the average, this language seems to me, to be a system you embrace because you're required to, for one reason or another; not because it's the best choice for any given application beyond some embedded web page eye candy.
Since when has allocating all my RAM in exchange for speed ever been a way to break a "myth"?
Ask anyone who's used a Java app. If you leave it open for a while, it'll take quite a long time to get it to continue because it uses so much RAM that it has to be flushed out to disk for me to use anything else. A "paper" cannot dispell personal experience.
Java has been hit hard about its slowness for a very long time. We all know about the tradeoff between memory and speed. And now Java goes to one extreme and tries to pass it off as if it's just as fast (and in some [nut]cases) even faster than C or C++. Sorry, but I'm not that stupid. I'd rather believe in conspiracy theories than believe the nonsense that Java is faster than C/C++.
Garbage collection is probably the single best cause of producing below par programmers. Some programmers think that because Java has a garbage collector that you don't need to deallocate your objects. This is really scary on many levels. Also, some people even go so far as to say because you don't have to worry about it (which is again false BTW), your software will run faster. I'm simply incredulous. It's like saying I don't have to worry about the amount of fuel in a car race.
Going with the analogy, Java runs fine on its first tank, but as soon as it gets low, it needs a fuel tanker. With C/C++, sometimes it may seem like it's taking slightly longer fueling up than it should, but that's because it's environmentally friendly and only consumes what it needs. Java uses a one-stop pit strategy where they steal fuel from the other teams and throws shrapnel in front of other cars. C++ is a well oiled machine that uses proper pit strategy and will still be around long after the other cars have been disqualified (killed and uninstalled).
I'll take C/C++ (Formula 1) or any other compiled language anyday over the ramhog that is Java (SUV).
If you had not noticed most mobile phones are pretty crap at obaying any kind of standards not just J2ME. The company I work for spends a huge amount of time and resources trying to get stuff to look the same on all devices. In fact the software to do that is our major product (again nothing to do with downloadable code (or java)). Just trying to handle the half arsed way in which mobile devices try to render WAP/HTML/CSS (and more importantly knowing which devices can handle which protocols) is more then enough. Let alone expecting them to write BREW (or java ofr that matter) apis well.
If you think that manufacturers will put much effort into properly supporting ANY standards then you are deluding yourself.
> C# has a LOT of syntactic niceties that Java doesn't
;)
The "override", and "new" keywords for methods are really nice. plus the "in" and "out" modifiers for method arguments too. Then there's the "using" compound statements.
C# the language really *is* better than Java. And I hate Microsoft as much as anybody else but then Nemerle is better than C# so I don't feel too bad about it
In my experience, Java's slowness issues stem not from the bytecode JVM, but rather J2SE's class libraries, and generally the object-oriented approach to solving problems.
Now, before you attack that, I'm heavy into design patterns and all the rest. No problem there, but consider this: how many times does an original piece of data get touched, copied or transformed in a Java app?
Case in point, parsing HTML or XML documents. Under the J2SE scheme of things, even a tiny XML document can result in hundreds if not thousands of objects being created, even if you're after just one piece of info in that document. That results from the *lazy* use of Java's built-in parsers, which are inefficient due to their abstract nature.
You have to carefully monitor where your data goes, and what gets done with it, in a Java application that makes heavy use of J2SE's classes. They're entirely general purpose, which is great when you need to slam out some code. But if you're at all interested in performance, you're screwed, because general purpose = glacial performance.
When I can, code state machine parsers for problems like this, and look for other ways to avoid the heavily abstracted code that can result in data duplication and slow performance. JVMs today are quick, and code written from fundamentals of minimal work can achieve maximal performance.
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
The Shootout Benchmarks are short-running microbenchmarks. Just-in-time compiled environments (e.g. Java and .NET) have a startup time that is as high as 100-200 milliseconds. You can imagine what that looks like in an Ackermann benchmark whose total runtime is 120 milliseconds. A 100-millisecond startup time matters less in real applications.
I converted the Ackermann and binary trees benchmarks from that site to run in a loop (to get JIT compilation happening). Java became faster than gcc. YMMV.
My company ships a desktop application with its own stripped down JVM, and the start time is very competitive with C/C++ programs. You double click the icon, the splash screen pops right up. We even had to add a sleep timer in there so that it would be guaranteed to stay up long enough for the user to see it. If we didn't do that, it would disappear within one second, which is all the time it takes to initialize all of the SWT interface stuff.
We also have a guy on another project that's working in C++, and he's constantly behind the schedule curve. Obviously one data point doesn't make a good case study, but I guarantee it's easier to go fix a NullPointerException that tells me its location than what he has to do to track down some obscure pointer bug.
Java and C/C++ are platform independent languages. Delphi is Windows only and owned by a company with a very questionable future (forget about Kylix). C# is basically Windows only as well.
As far as productivity, it depends what you're doing. Java UI's take longer to implement (that might not even be true for SWT interfaces) but the core language of Java is very fast to write code in. Regarding startup time, Java can take longer but these days you have the option of specifying what role your app will be playing: a long running server app or a desktop application. The latter is designed to start up faster.
And finally, no language is a silver bullet. You need to factor in a lot of things when choosing your programming language.
> Delphi is Windows only and owned by a company with a very questionable future (forget about Kylix). C# is > basically Windows only as well.
The Borland implementation of Delphi is, but others aren't:
http://lazarus.freepascal.org/
We need to do something similary.
Do you have any documentation on how you stripped it down?
And how about the legal problems? The license for the jre say that you are not allowed to remove ANY part of the jre, except thoose mentioned in a very short list. -(
There's nothing that turns me off more than the one-size-fits-all zealotry that often comes from the Java camp. One size does not fit all. It never has, and it never will.
Programming languages are tools. Pick the appropriate tool for the specific job. More specifically, understand the capabilities and deficiencies of a wide range of languages and map those appropriately to the specific problem domain you've been asked to tackle.
Examples:
*) Production quality, single-user, cross-platform application: Java is at the top of my list.
*) Production quality network service with deterministic behavior under load and soft-to-firm response-time requirements: Hard to beat C w/ Linux here.
*) Quick and dirty lab-only tool to thrash through some test results: Yep, it's Perl.
Engineering is all about trade-offs. Understanding your problem and the tools you have to solve it with are critical. Making a poor choice, especially early on, can be disastrous. Even though I don't discount the performance enhancements Java has enjoyed over the years, I'd be very hard-pressed to select a virtual-machine based language/system for any performance critical application requiring a deterministic response.
Pounding a square peg into a round hole by insisting on one language for everything doesn't demonstrate a lot of design-maturity or sophistication on the part of those making such claims.
I've worked this into my interview questions for new hires as well and have found it to be a pretty good indicator of who I'm dealing with, experience-wise. (hint: the guy who insisted on smalltalk for everything did not get the job)
Hold on a moment, there are a lot of errors here!!
) ;
It's Java, it should be:
System.all.group.second.half.of.coders.grab(stone
"Delphi...owned by a company with a very questionable future"
I first heard doubts about Borland's future in 1984. Even then it was a commonly held belief. Well, you just keep repeating it. Since nothing lasts forever, you are bound to be correct one day.
All anyone has to do to determine java is slow is run a practical application written in java. You can give examples and hypothesis and benchmarks all day long. It still won't change the fact that I can put a java app on joe blows desktop and will get a, "Damn this is slow." comment with all but the most trivial apps, each and every time.
Java, as Larry Wall stated, is one of those "stay-at-home" competitive language that works best in a pure environment. As opposed to say Perl which is a regular party animal and plays well with everything. Although, I have to say, I've never had the occasion to invoke Java from Perl.
Java programmers design code to object oriented methodology and do not design primarily for performance. Java is not a systems programming language. Java is a software engineering language designed to optimize human time and not computer time.
If one is going to start a project with performance as the top priority, one would not design it in Java because most assuredly one is not going to have the luxury of a homogeneous environment but will need to play well with others using a language like C/C++. Case in point are databases. Java's interface to MySQL is still slower than C/C++ or Perl.
The question is how best to balance human performance time with the software engineering design philosophies that optimize human time in languages like Java with that of computer performance time and systems that lie out side of the Java native spectrum and defeat the "stay-at-home" homogeneous design requirement of not playing with other languages like C/C++, COBOL, etc.
If a performance project requires heavy integration and interaction with multiple systems outside of Java one would not choose Java, but one could choose C/C++.
Also one more point I would like to make: The point of Java is write once run anywhere. Sure in theory I can use the same application on multiple operating systems. The problem is that many of them have specific version requirements for the JVM I am using. Even with 2 or 3 Java applications on my PC there is a trial and error process of trying to find a JVM that all 2 or 3 applications can run on.
So I can write _one_ application and run it anywhere, as long as noby elses Java application using a seperate JVM version is already there.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
"You double click the icon, the splash screen pops right up. We even had to add a sleep timer in there"
Ah yes, greatly optimise and then throw it all away just so you can remind the user can catch a glance at that big shiney (but expensive) version number...hey! that number could be a bit higher couldn't it?
Is there an option in your app to disable the splash screen?
See, that right there is a huge chunk of the whole problem. If programmers weren't being lazy and arrogant jerks and assuming that nobody cares about how poorly designed and coded their algorithms are, or how blatently horrible their memory usage is, we would have a lot fewer problems.
I don't care that Java will get there at some point, or that it's better now. I care about whether it actually works right, and right now it does not. It does have too long a startup, most of the UI toolkits are horribly slow, it does not follow native platform UI conventions, and it is just not as nice to use a Java app as it is an equally well written native app. It does take far too memory, especially compared to other languages. Even the cross-platform nature of the code is largely a lie. Different JREs don't support the same things, and many platforms lack a JRE. There are massive differences between the various editions of Java so as to make it useless to try to write something across them. Your Java app written against "Vendor X Version Y Edition Z JRE" should work fine on any other platform with the same version of "Vendor X Version Y Edition Z JRE". That's all you can safely say without a good amount more testing.
However, most of all, my CPU time and RAM might be cheap, but they are abused every time I use an application written in that mindset. I have memory needlessly abused, and CPU time needlessly wasted every time I run some poorly coded program. That means that I lose time and productivity every time I run your poorly written app. That attitude pisses me off, why we should all squander our system resources so that a few lazy programmers can write some app a little faster and with less effort, rather than doing their job right.
Programmer cycles are a lot cheaper than making thousands of people upgrade their hardware. I imagine those programmer cycles are a few orders of magnitude cheaper.
Java is fast enough for most tasks, and the GC is a wonderful convenience.
But let's not go overboard. I started writing a 2D vector game in Java a couple years back that included rudimentary physics. I tried the Windows, Linux, and Apple JVM's at the time, and as things got more complicated I ran into a lot of performance problems, namely, a notable split second lag every couple seconds where the GC would kick in and lock everything. After trying every trick I could find, I converted to C++ and got an immediate huge performance boost -- well over 10x -- without any further optimization.
I'm sure JVM's have come a long way, but I just fired it up under the latest Apple JVM (I'm sure folks will tell me that's the worst one...) and the performance was still notably less than the C++ version.
I'm not trying to put Java down, here, but let's not make pretend it's super fast. It's not. Neither is perl, my day-to-day language of choice. But that's okay because different languages have their place. C++ is fast. And frankly, when I did the Java to C++ conversion, the code didn't even look much different.
Enjoy whatever you use...
And I've never seen malloc/calloc/free anywhere among the top time-consuming functions...
Maybe, Java's allocation/deallocation is even faster, of course.
In Soviet Washington the swamp drains you.
Until a JVM implemented in pure Java works as well as a JVM implemented in C/C++ (like all of today's JVMs), Java's still slow.
They got the concept right. The implementation is crap.
it's not that GC is slow, it's that the comparison is invalid. malloc libraries are designed to minimize or at least keep low the amount of wasted space. GC trades off extra space for the performance of contiguous arena allocation. malloc could do that too, and its fast path would be identical. the slow path matters, too. further, a GC language necessarily trades off contiguous allocation vs some sort of indirection or pointer-editing. that is, GC has to be able to move memory objects, so the simplest (historic, inefficient, naive) implementation is to always just indirect through an object table. that extra memory reference is much more important than shaving off a few cycles of the allocation fast-path, since the cost is taken on every reference.
Startup of Java seems a little slower than CLR but not markedly slower. Mono's startup is hardly a speed demon either. In all, I think most of the hype around the CLR is just that - hype. The CLR is a lot nicer virtual machine, and C# is as close to C++ / Java that I couldn't care which language I'm writing to, but the performance differences are IMHO neglible.
As an example of how fast Java is, I have written a poker simulator which plays 1000 games from a deck of cards which is shuffled 1000 times for each game. The hands from each game are then sorted, and scored. It's very Vector and LinkedList intensive and each loop probably sees a dozen or so temporary Vectors or arrays used during comparison - i.e. 1,000,000 iterations with many more nested within. It takes just over a second on my 1.8 Ghz PC.
As far as I'm concerned, that's plenty fast. I reckon I could probably halve the time if I bothered to replace all the vectors with fixed arrays.
It would be hard to compare Delphi (as in traditional Delphi) to either C# or Java since it is a compiled language. I don't know what Borland are doing with it these days so I wouldn't be surprised if it's gone the CLR route too.
Gah. If you use C (or better, C++), and you like it, and you like garbage collection, why not just use a garbage collection in C? I haven't written anything particularly huge lately, but the Boehm-Demers-Weiser one seems pretty solid. It's the best of all worlds -- you let the garbage collector handle most of your memory recollection. Remember the 90-10 rule ("90% of execution time is spent in 10% of the code"), so if there's a chunk that really needs manual allocation you can do that too. And the performance? Wonderful! Bump-pointer allocation means new objects get there fast.
There's no such thing as a wart-free language, but in C++, lack of garbage collection isn't one anymore.
When processor cycles are expensive you use something fast in execution, like C.
When programmer cycles are expensive you use something fast to write in, like Python.
When brain cycles are expensive you use something an idiot would choose, like Java.
malloc is a function, and when you call functions the stack is used to pass parameters, so no matter how clever you write your heap allocator it is always at least 2 stack frame allocation more work than a stack frame allocation!
(1 to allocate a heap block, 1 to free a heap block).
And that ignores the heap searching algo overhead.
Your stack allocations are totally free, because they are allocated when your function is called.
Or, if you are doing web apps, use Ruby on Rails. You'll never look back.
I find it rather amusing that these "studies" claim the JVM to be more efficient that C/C++ when the language that the JVM is coded in is C/C++ (or a like language).
Bloody rediculous.
The only way that they are going to get favourable numbers is by cooking them... big surprise.
irony.
Garbage collection will never be as efficient as direct memory management.
Slightly OT, but why do people put C and C++ in the same performance class ? The performance difference between the two is quite significant, especially if you use gcc/g++. I once try to port a big project from C into C++, without actually converting the code into classes (not a big deal, since the incompatibilities were really small). At some point I had the code compile under both gcc and g++. Interestingly enough, with g++ the code was about 30% slower.
The Raven
There is a whole 'nother source of Java slowness -- the JVM startup and loading the classes used by your app. It is not just that some Java apps are slow, they take forever to get going.
Similarly, why should we risk forgetting to deallocate stuff from the heap, when we can have the computer do it itself?
Because you don't want to risk falling behind on the incoming and outgoing signals. A lot of the applications of embedded devices and handheld devices are signal-processing applications, and they must run in some semblance of real time. Even video games are soft-real-time signal processing applications that turn signals from the controller into video and audio signals. When you need to maintain a (hard or soft) latency guarantee between the input and output signals, you have to design for the worst case, not the average case. Taking a break to GC the heap is often not an option. Or has incremental collection on the heap become as fast as malloc/free?
Unless, like me, you're the guy who's writing that library that everyone else depends on, in which case the two are the same thing for practical purposes. In that case, trust me, you still use something like C or C++.
Here are a few reasons why:
Any of those in isolation is game, set and match against the arguments in the article. Put together, you get the same picture most of us have painted all along: Java's performance is adequate for non-critical tasks, but it's nowhere near the top of the pile when it really matters.
BTW, in case anyone's wondering: yes, I do work on widely-used, performance-sensitive mathematical library for a living, and yes, as it happens I really have spent the last few weeks researching ways to increase the performance of that library even further.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I don't know about netbeans, but I use eclipse (3.0 and 3.1) more than 8 hours a day and it is not slow. I have 1GB of RAM, but next to eclipse I'm running a weblogic (development) instance and lots of other normal office programs, and eclipse works very fast. It is really amazingly fast for such a complex GUI program. It has a very complex with lots of tabs, menus, browsing trees everywhere on the screen, all kept up to date in real time.
Please, give it a serious try since your experience, the non-trivial last of which must be at least several years old. Slowness of Java is really a myth. It is very very irritating to see that myth kept alive by people repeating each other (and of course MSFT) for the last years without being open to review.
Yes, any Java GUI app written in swing crawls unless it has a lot of memory and a good CPU behind it. But that is because swing sucks, not Java itself.
Or, to put it differently, "having sucky java apps is optional". Computation and networking can be pretty nippy. Because threading is easier, you can also make use of multi-core systems quite easily.
What you cannot do in Java is go low-level when you need to issue cache prefetch opcodes, or directly address the SS2 parallel register set (Java1.4+ hands off all floating point operations to the SS2 registers/opcodes, but doesnt SIMD parallel ops).
At the same time, how often is top-tier performance really needed. For many programs, time to market with stable apps matters more. This is potentially Java's big weakness: successor languages (e.g. Ruby) that offer even better productivity, without making performance tangibly worse.
You can write high performance, CPU intensive code in Java. If you don't believe me just download jrMan and try it. If you want to compare with a C++ implementation you can download Aqsis which implements the same algorithm to render images.
Not only are the J2ME specs incredibly loose and full of optional material, but nearly every phone has bugs in their implementations. Apparently Suns engineers have never heard of "conformance tests" - even basic stuff like drawRGB to negative co-ordinates doesn't work right on most phones.
Worse though is Java itself. The Java compiler provided by Sun is an absolute waste of space. It does virtually NO optimisation itself, relying on the JVM to do it all, which is great except the micro-edition "kvm" runtime doesn't do any optimisation either because they didn't have space to make it do more than the very basics. Worse, all the usual flaws it has are still there - an asinine insistence on treating unreachable code as a fatal error, lack of a pre-processor (which you need for mobile development as phones are so different), etc.
Javas runtime performance is atrocious. Only the very newest phones run it anywhere near acceptable speeds if you're doing anything graphics "intensive" (like basic animation). Instead of pre-compiling the code to native at install time, which would seem to be the obvious solution, the KVM still seems to use just-in-time compilation.
The biggest difficulty though tends to be heap fragmentation. Most phones do not use a compacting GC, with the result that it's very easy to make an app that runs fine for a few minutes then barfs because the heap has become fragmented. Java desperately needs manual memory management extensions, stack allocation or the ability to run multiple heaps but instead Sun are simply pushing a micro-edition of HotSpot - apparently waiting for the hardware to catch up so they can cover up what a useless hunk of junk Java is. It's alright for the article to talk about escape analysis - a technique that isn't actually implemented in any shipping desktop or server JVM yet, but how many years would it be until such a basic thing as allocating objects on the stack instead of the heap runs on mobile phones?
There are only two reasons to use Java on mobile phones - the security, and the number of people who know Java. Unfortunately although there is a huge market of (cheap?) Java programmers, people who know Java but not C++ are likely to screw it up because they don't really understand what's going on underneath the hood and so don't understand how to write efficient code.
The java vm startup time is a problem for client apps, but server side its not a big deal.
This is yet another urban myth about Java. I have a 1.8GHz machine. Java 1.5.0_04.
JEdit starts up in 3 seconds.
The jsf demo Notepad.jar starts up in 2.5 seconds.
SwingSet2 - the full Java GUI demo starts up in 7 seconds.
So where is the problem?
With Java you get all these optimizations, not necessarily for 'free'. They are given to you based on whose JVM you choose to use. So you stick to applicaiton code, and let the JVM writers handle the GC and memory code. Anyway you look at it _somebody_ is writing that GC and memory code; Even if you choose to program in Java, the GC/memory portions are written in C/C++ anyway. And yes, while my program has been the same since 1999, the jvm its run it has gotten better so now my program is better and I have not touched in in 5 years. Woot \o/
The comparison is foolish. You can't compare C/C++ to java. You can however compare C/C++ to a particular implementaiton of Java such as the sun 1.4.2_09 JVM or the sun 1.5.0 JVM, etc. Anything else is apples to oranges.
Unless, like me, you're the guy who's writing that library that everyone else depends on, in which case the two are the same thing for practical purposes. In that case, trust me, you still use something like C or C++.
Horses for courses.
In the 1% of programming projects where this is true, it makes sense to use the right tool for the job like you're clearly doing.
In the other 99%, requirements aren't so stringent in that direction, but might be towards, say, the cost perspective, in which case again, Java-like languages and environments are appropriate.
There are incredible advantages in standardising on a platform such as Java, and planning forward in such a way that the organisation is able to make exceptions in cases such as yours, where it makes good business sense.
Or, if you are doing web apps, use Ruby on Rails. You'll never look back.
Unless you need to make dramatic changes to your database schema. Or have to port to a different database with different SQL and column naming conventions. They you will look back a lot.
Delphi now compiles to .NET code, and .NET runs on Mono, which runs on several platforms. It's not Windows Only. The compiler might be, but the output isn't.
If you need web hosting, you could do worse than here
Are you adequate?
J2ME JVMs are so buggy and inconsistent that JAMDAT has to create 100 different builds and packages to support different J2ME VM bugs and different screen sizes and resolutions.
cpeterso
And this is supposed to be good? How about applications that you want to startup in a fraction of a second? Imagine if every time we did an ls, grep,... in Linux we had to wait up to a minute for it to start up.
The incredible startup overhead of Java is absurd. I wrote a simple mathematical browser applet whose equivalent in C runs in perhaps 10 msec. The Java applet it takes almost a minute of disk thrashing on a 2GHz machine to initialize, which is like 5000 times slower - not 20% slower, not twice as slow, but 5000 times as slow!. Yes, once it starts its speed is reasonable, but the applet is supposed to let you instantly do an occasional calculation and be done with it.
I have been using Java for a long time, for server software, server-side methods and client-side applications. In general, through not always, interacting with databases. I have also written C++ code, both for similar purposes and for hardware control.
My experience is that in a well-written Java application, the performance of the JVM is usually not the real cause of performance bottlenecks that can be felt by the user. Design errors can make Java code slow; it may be a relatively "easy" language but the programmer still has to understand very well what he or she is doing, and seemingly unimportant choices can have serious performance impact -- just as in C++.
Fortunately, understanding the system is much easier in Java than, in say, Visual C++ (to mention just one abomination from the deep.) I suspect that on average Java code contains fewer blunders with a serious performance impact than C++ code.
Certainly, for the really high-speed parts of the code and for specialized purposes I too would still recommend to use C++, but for 95% of all code there is no reason not to write it in Java. And it is fairly simple to integrate C++ code in Java.
I harbour a suspicion that programmers who insist on writing all code in C++ or even C because they think that it will be faster, are largely the same people who insist on writing labyrinthine, unstable and unmaintainable code because they think that is faster. As you may suspect, I don't have a high opinion of programmers in general: I think that in general, only a third of professional programmers can be called competent (enough) to safely handle tools such as C++. The rest should be kept in to a sandbox.
And besides, the majority of infuriatingly slow applications that I have seen were not written in Java: More typically these are the work of naive Visual C++ and Basic programmers, the kind of people who recalculate the layout of the entire screen when they need to change the display of a variable, or copy the content of an entire database to memory on start-up.
A caveat, however: Java performance can depend enormously on how your system is set up. For example, the way the on-access scan of McAfee antivirus handles the Java JRE and other libraries is a bloody disgrace and results in painfully and unacceptably long startup times. But that is hardly Sun's fault. (Note for the next job interview: Ask what virus scanner they use.)
I admit that relying on garbage collection can be unnerving for the C and C++ programmer. I think I was nervous about not explictly de-allocating memory for the first two years or so; then I got used to it. (And, despite finally acquiring Java habits, I do not forget to de-allocate in C++ code. If anything, I am more accurate in it than I used to be.)
Ironically -- and this should serve as another caveat -- the biggest memory leak I ever created was in Java, not in C++. What I had overlooked is that the GC will not get rid of memory if a reference to it has been passed to a dialog; and I had forgotten to dispose of the dialog, which (very indirectly) controlled the display of a large data set.
The problem isn't application code typically, its the VM startup time people complain about. If java is already running its fast, but if you are starting a vm from scratch (server vm in particular) it takes a few minutes. As an example, it takes 35 seconds to start up tomcat on my freebsd server including VM startup (java 1.4.2 native) and loading all the webapps. I've timed it.
Server specs are a p4 2.4ghz with 1gb ram and freebsd 5.4 release.
MidnightBSD: The BSD for Everyone
While I agree that in theory, and in labratory conditions, Java is just as fast (sometimes faster) than C/C++, in practice it doesn't usually end up that way.
.NET available instead.
The way normal people write code, and the libraries and functions that normal people use, java is slow as snot. I don't care why that is, it just is, and it makes me steer away from Java client applications if there is something that is native or
Real world results are different from labratory ones as far as Java is concerned in my book. And that's just my experience.
If you need web hosting, you could do worse than here
Garbage collection is not a magic bullet that makes memory leaks dissapear. You can forget you have a reference to something just as easily as you can forget to free something.
Let me see here: on the one hand a C program will possible run very well in a particular environment. A interperted langauage- has to do several things- including guessing your hardware, optimise itself, not crash etc etc. and lets not forgot many of these things are done while your using it. I used J Office and was impressed. It did what I could want it to. Sure it had some bugs, some more anoying than others. Just my opinion is its issues were minor compared to the offic 2k (in fairness to office it was just released of OS X). Java 1.x sucked- plain and simple- it was terrible buggy. Java 1.5 sucked less. Java 2.0 is practicly a rewrite and works. I do agree the initial run of java applications is not particularly good. (J-office took 15 minuts the get going first launch. The second launch was 10. then 5 then just a few moments.) However it seemed to be as well written-suposedly their is a multithreaded edition that's even better and sexier.
I can write half the code with C#.NET than to implement it similiarly in Java. Also VS makes it alot easier to write gui components than Eclipse. .NET is really nice
As soon as you go to a website and seed the dreaded .jsp extension, you know you're in for a wait.
All the websites that use Java are just ridiculously slow. Name one that isn't.
Could you imagine Google running Java and some JVM?
Anyone that complains about java's being a bad language-How many of you are using Limwire or Azereus?-Your using Java
i've never noticed much difference in performance in c++ or java, except when writing gui apps and using swing with java. swing is slower than any gui toolkit you can use in c/c++, at least any i've used. but non-gui java apps never seemed slower to me, who's been saying this?
Spiral out. Keep going...
Summary: "If JVMs were smart, garbage collection would be fast."
Reality: "JVMs are mostly very stupid, and you can never be sure what JVM your users are going to use, so in the real world of deployed applications garbage collection performance--and Java performance generally--is a nightmare."
I am so tired of GC advocates talking smugly about theoretical scenarios. Who cares?. When I can run a Java app on an arbitrary JVM and not have it come to a grinding halt every once in a while as the garbage collector runs--or worse yet bring the machine to a grinding halt because the garbage collector never runs--only then will GC will be useful.
The weasel-words in the article are worthy of a PHB: "the garbage collection approach tends to deal with memory management in large batches" Translation: "I wish GC dealt with memory management in large chunks, but it doesn't, so I can't in all honesty say it does, but I can imagine a theoretical scenario where it does, so I'll talk about that theoretical scenario that I wish was real instead of what is actually real."
This is not to say that there aren't one or two decent JVMs out there that have decent GC performance. But having managed a large team that deployed a very powerful Java data analysis and visualization application, and having done work in the code myself, and having had to deal with user's real-world performance issues and having seen the incredible hoops my team had to go through to get decent performance, I can honestly say that up until last year, at least, Java was Not There with regard to GC and performance.
The most telling proof: my team did such a good job and our app was so fast that many users didn't believe it was written in Java. It was users making that judgement, not developers. Users whose only exposure to Java was as users, and whose empirical observation of the language was that it resulted in extremely slow apps. They didn't observe that it was theoretically possible to write slow apps. They observed that it was really, really easy to write slow apps, in the same way it's really easy to write apps that fall over in C++, despite the fact that theoretically you can write C++ apps that never leak or crash due to developers screwing up memory.
Every language has its strengths. Java is a good, robust language that is safe to put into the hands of junior developers to do things that would take a senior developer to do in C++. But its poor performance isn't a myth, nor is its tendency to hog system resources due to poor GC. Those are emprical facts, and this article introduces no actual data to demonstrate otherwise.
Blasphemy is a human right. Blasphemophobia kills.
On the other hand, we absolutely cannot do without C or something very much like it. What else would we use to write the JVM in? And Perl?
C is getting old, we need a replacement. C++ is too complex and error prone; At least -- we know we can do better than either C or C++ and keep the high performance. Look at the D programming language, as a proof of concept. Can we do better than D and keep the performance?
I18N == Intergalacticization
Oh, and deligates are another "beyond-syntax" feature that C# has and Java doesn't that IMO leads to MUCH cleaner code for stuff like interface design.
I believe that, directly or indirectly, an unjustifide emphasis on execution speed is the one of the biggest causes
of the failure of software projects. The problems usually begin with the choice of
implementation languages. Programming languages should
be chosen for the ease and cost effectiveness with which they can be used accurately and reliably generate
a correct and maintainable application that satisfies the customer.
In my experience selecting a language because it is "faster" than another language
before it is even known what the speed issue is for an application is just a costly mistake.
For speed critical parts of an application an experienced C++ programmer might be a without-which.
A tool like JWrapper can be used to connect a Java application to an optimized C++ library.
Speed requirements should usually be dealt with towards
the end of the development. Most of the execution time is usually spent in a small fraction of the code.
Only that portion of the code should be optimized because optimizations can be costly to derive and implement,
costly to maintain, and more difficult to verify.
In the interest of peacefull coexistence we might all agree that:
1. Java is sometimes too slow
2. C and C++ programs sometimes have memory leaks.
3. Writing efficient, reuseable, object oriented programs in C++ can be an extremely subtle business and,
as a result, good and efficient C++ programmers are harder to find.
And SciTE starts in roughly 0.5s... (the "true" notepad startup time being more or less null, making it just about infinitely faster than java)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Nope, not compared to Python or Ruby (which yield codes rougly 5 times smaller in a quarter of the production time), not compared to Lisp for an ol'timer, not even compared to C# (by a quite small margin though, but C# has a lot of very nice feature Java doesn't have).
Writing Java is faster than writing C/C++ indeed, but not "very fast", not without any referential to compare to, because dev-time wise Java gets it's ass handed to it by much more agile languages.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
A quick web search turns up several surveys with lots of benchmarks,
http://java.sys-con.com/read/45250.htmr k.html
http://www.idiom.com/~zilla/Computer/javaCbenchma
This is about as much of a myth as the myth of the earth traveling around the sun. There is a lot more to allocating memory than this article lets on. Psuedocode will always be slower than machine code no matter how you slice it. You can do various tricks to make it seem faster by instruction count at certain things but in the end those same things can be applied to compiled code like c/c++. Most people can accept that as fact and move on using Java where it seems appropriate. Make all the excuses and extraordinary claims you wan tint the end Java is just plain old FAT n slow, anyone in any programming course who has used java can tell you that.
Oh and it is hard to test out his little theory on the free malloc in C++ because you can't do the same thing in Java. You can try but it will get around to the free part when it gets good and ready and may not attempt the malloc until you use the memory.
Ermm, one question: is your poker simulator multi-threaded? If not, try ArrayLists in place of your Vectors in the Java code. Vectors are internally synchronized, which will hit you for a pretty big performance penalty.
Sorry, Vector over-use is one of my pet peeves. It's silly little programming goofs like this that make our programs slow, and give the anti-Java trolls more ammo.
"In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
Certainly much of the Enterprise business world I've interacted with is under the same impression as this statement so you are in good company. Except that last part "And it is fairly simple to integrate C++ code in Java." . I'm curious if you could speak to your experience on how is it fairly simply to integrate Java with any other code. The JNI interface is very error prone and can have huge impacts on performance. When I consult for people wanting to interoperate Java with some other language the best solution is to go through some known interface protocol like SOAP or HTTP.
In fact, sometimes the best way to interoperate distinct Java programs is to isolate them within different JVMs on different machines. Companies like EBay implement what they call "use case" machines where hardware isolates Java software release and performance problems.
Java runs best as a SUSA environment, single user, single application. Java's JVM doesn't do well at all as MUMA, multi-user, multi-application environment unless you have a highly customzied environment as with web application servers. Web application servers are really a misnomer. They are not application servers. They are JVM environments that allow Java to scale to MUSA, multi user single application. The raw JVM assumes one application, one user in my opinion when one is considering performance.
Java allocates objects linearly, i.e. it simply increases an index. When that index reaches the top of the garbage-collected memory, memory is defragmented.
C++ and C have quite complex algorithms that search lists of blocks for either the biggest size or the closest to the requested size. In reality, manual allocation is slower than the Java model.
But there is a very important problem with Java that C++ does not have: Java allocates all its objects on the heap, whereas in most C++ apps most objects live on the stack. This little difference makes C++ programs faster, even though allocation of Java objects is significantly faster.
Another problem with Java is that Swing is slow, and therefore Java apps are perceived as slow. But it is only Swing that is slow, because Swing implements its own Window system, complete with region geometry.
In the end, Java wins for me, because I simply don't have to track down pointers as in C. From the day I started to use Java, my productivity has skyrocketed, even if my programs 'feel' a little slower.
So, tell me, how is C++ implementing virtual method calss, without virtual method tables? Oh, and yes, fuck this synchronisation stuff, one thread will be enough for all applications!
If a C++ class has virtual functions, there will be a virtual method table. However, if it doesn't, there will be none. A simple class for data storage will have zero byte overhead. Add synchronization (I think you mean semaphores?) and this will cost you that extra few bytes. But only when you need it.
A Java object always comes with overhead, there is no way to get it out. The big difference between the philosophies of C++ and Java are that in C++ you don't pay for what you don't use. In Java you simply pay for everything, even if you don't need it. Don't need inheritance, but only data encapsulation? you pay for inheritance. Don't need synchronization? You pay.
Just a question: how much memory does an ArrayList<Integer> of size 1000 take? In C++, a vector<int>(1000) takes 1000*4 bytes + 12 (3 pointers for vector). Last time I checked, a single Integer in Java takes 16 (!!!) bytes, 4 times more than strictly necessary. Arraylist itself comes at a nice 80 bytes (versus 12 for C++). Further, how much would a non-virtual class in C++ take that has a single integer data member? Yes, again 4 bytes. Add a virtual function table, and you're at 8 bytes, still half of that of Java. All these unavoidable bytes quickly add up, hence Java being a memory hog. One million of objects floating around? (can easily happen as you hardly have a choice avoiding objects) Eight megabyte gone for Object overhead alone.
I recently decided to try out Eclipse - after hearing how brilliant it was - to replace Anjuta for C++ development. I notice an eclipse package is in Debian so I "apt-get install eclipse-sdk". Oh, it needs a Java SDK first. No worries, I'll just install one of those using apt. I'm sure this will be easy.
Easy? Hah! Maybe it's easy for x86 users but us PPC users are out in the cold. After hours of fruitless searching I eventually chance upon the IBM Java SDK on the IBM website. It's only in RPM format, but a quick "alien" later and I have a package. I install it, go to run it, and the JRE crashes.
So I simply delete the Java SDK and any hopes of using Eclipse on Linux/PPC. I'm not going to jump through hoops; if it doesn't "apt-get install" then I don't want to know about it.
I always find it interesting to see how many C/C++ programmers think manual memory management is "fast". I think anybody spouting off about such topics should be required to have least *implemented* a fast malloc()/free(). It's a non-trivial task, and when you see that the hot-path is still dozens of instructions long, it really puts the cost of malloc() into perspective.
A deep unwavering belief is a sure sign you're missing something...
Eclipse and its parent project, IBM's WebSphere, are mighty big "exceptions" in the Java world.
.NET or Java -- if your target end-user environment consists solely of your standard, homogenous x86/Win32 systems? Why not compile a native binary instead, which will run faster and be leaner in RAM and on disk (and thus, faster to distribute over a network)?)
I agree though that C# is no better. VMs will always eat RAM and CPU time, and the vast majority of the time, they do so unnecessarily... (why run an app in a VM --
I do find it a bit humorous that you refer to your G5 as "older". The current top-of-the-line Apple box CPU generation is "old"? Hardly.
Is Capitalism Good for the Poor?
So does JVM i/o performance, specifically disk, still suck the big one when dealing with moderate i/o loads?
I believe that this battle can be summed up in the battle of Java vs. PHP. Here we have a fully OO VM based language that has been widely deployed on both Unix and Solaris, vs. a (mostly) UNIX only scripting language turned web programming language with lots of web-specific features. I have developed large solutions in both languages, and it really comes down to: PHP rocks for quick-and-dirth websites. Put a PHP next to a Java guy to develop a basic ecommerce or content mgmt website, and PHP will TOAST that guy. Now required six-sigma reliability, 100+ hits per second, redundant servers w/ clustering, the ability to connect to multiple corporate database from different manufacturers, and other high-end enterprise features, and Java wins hands down. Not to mention of the security of PHP vs. the security of Java - PHP is "wide open" in many ways. USE a big hammer for a big nail, and a small hammer for a small nail. Java ran WebMD (many thousand hits per second, all data driven) with an early version of Java 1.1. - yes, we need to clean up the socket code some w/ SUN, but it worked, and it worked very well. The future looks to me .NET - Microsoft was brilliant - a well defined software app network architecture what is language agnostic. This time in a few years there will be many Java programmers writing web-service code behind the .net standard.
Thanks for reading my stream-of-consciousness.
Horns are really just a broken halo.
The return of Ada95! (Seriously, in the C# language manual they even mention Ada!)
Need help treating your acne? Come here!
Yes, exactly. Java's performance hasn't suddenly found a silver bullet that enables it to beat well-written C or C++. However, for most applications, that doesn't matter.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Therefore it makes sense to sacrifice a little bit of program performance to get more productive programmers.
And therefore, all enterprise development should switch to using Ruby.
Karma: It's all a bunch of tree-huggin' hippy crap!
Hey screw you! What makes YOU think that YOU have the right to eat at my system's memory so I have to go out and buy more? You're a programmer? So what, your job is to write applications for the END USER, not to write applications As It Is Convenient To You.
Besides, if EVERYONE takes up 100 Megs of Memory (about what the JavaVM with Eclipse running takes up, and my Explorer.exe process is sucking down another 100MB, and Acrobat is taking 32MB just with a single file loaded) pretty soon 1GB will not be enough, so users will upgrade, so programmers will think "hey we have more room to work with now" and they will get lazier and eventually 2GB will not be enough...
It is stupid, REALLY stupid. Why should a text editor take up 100MB of RAM? Why can EMACS have a boatload of features (CD-Burning...) and take up less memory than a freaking
Let me tell you why, it was because even with the GNU's non-conservative programming tactics (Stallman says in his Manifesto than the GNU during its founding years did not work to conserve memory, in the belief that computer power was expanding so fast that to do so was meaningless), they did not have such an ego about them as to abandon effort all together and just throw their apps willy nilly.
Oh, and for the record, Dell's low end Dimension systems STILL ship with 256MB of RAM standard. At least now MOST of Dell's Business workstation's come with at least 512 MB of ram.
VS2005, with a decently sized project open, 300MB of RAM or so. I had a 512 system, I could MAYBE browse the web while running it, had to deal with a lot of disk thrashing though.
So tell me, with half a gigabyte of memory, why should my disk be thrashing like mad because I dare to have both an IDE and a web browser open at the same time? Don't tell me it is MS's fault, they are just following in the trend that Sun created: Please the programmer, forget about the end user.
Of course with all of this running, Developers need a good 2GB+ of memory on their computers, which means they loose site even more of what kind of system's their end users are working on.
Need help treating your acne? Come here!
And SciTE starts in roughly 0.5s... (the "true" notepad startup time being more or less null, making it just about infinitely faster than java)
I would be interested in an explanation of how a 2.5 second startup time has any relevance whatsoever to the general user.
Symbian C++ isn't that difficult, it lacks documentation though. That's being worked on.
The problem isn't application code typically, its the VM startup time people complain about. If java is already running its fast, but if you are starting a vm from scratch (server vm in particular) it takes a few minutes. As an example, it takes 35 seconds to start up tomcat on my freebsd server including VM startup (java 1.4.2 native) and loading all the webapps. I've timed it.
Server specs are a p4 2.4ghz with 1gb ram and freebsd 5.4 release.
I am talking about VM startup time - that is included in the 2.5 seconds. I'm sorry, but server VM startup time does not take a few minutes, at least not on machines I deal with.
Let me give you an example: AMK K7 - 1.8 GHz, 512MHz ram. Java 1.5.0_04
The issue you are dealing with is the loading of all the webapps. This has nothing whatsoever to do with the VM startup time. A typical Tomcat installation may have to deal with half a dozen applications, all with security issues, JARs to load, and database applications to establish. It is basically like starting up an operating system!
If you get bare tomcat (I use 5.0.28) I have found that I can access the management application only 5 seconds after startup.
If you are going to comment on VM startup time, you need to test an application that actually measures that.
Let's take these myths one by one.
... 3 megabytes of memory.
I am using an AMD K7 Machine, Linux, 1.8 GHz, 512 MB memory.
It does have too long a startup,
JEdit, a popular Java programmers editor. Start up time 3 seconds.
most of the UI toolkits are horribly slow,
On the same machine I am using NetBeans. There is no delay in menu use, dialogs, text editors.
it does not follow native platform UI conventions,
On MacOS/X it follows native platform UI conventions exactly, as the implementation was written by Apple. On other platforms you can use SWT which not only follows the native UI, it IS the native UI! On the upcoming version of Windows, Swing will be guaranteed to be undetectably different from the native UI by both Microsoft and Sun.
and it is just not as nice to use a Java app as it is an equally well written native app.
Nice is subjective. Both NetBeans and Eclipse have won developer.com open source awards, so I guess a reasonable number of people find them nice.
It does take far too memory, especially compared to other languages.
I can start up the Java Swing Notepad demo in
I can start up the Java full GUI demo (SwingSet2) in 10 megabytes.
I can run the Sun full-featured NetBeans IDE in only 64MB.
Not my definition of 'far too much memory'.
Even the cross-platform nature of the code is largely a lie.
Nonsense. I use this nature of Java on a daily basis, as do tens (if not hundreds) of thousands of other developers. If you looked at the surveys you would see that it is entirely routine for developers to use both Windows and Linux to develop Java and to deploy on the other platform.
Different JREs don't support the same things.
They absolutely do if they are the same version of the JRE. They have to pass a compatibility test.
There are massive differences between the various editions of Java so as to make it useless to try to write something across them.
Well of course not! What do you expect? Do you expect the same binary program to work with different version of Linux or libc? Java is pretty much guaranteed backward compatible, but why should anyone expect a Java 5.0 app to work on Java 1.3?
Your Java app written against "Vendor X Version Y Edition Z JRE" should work fine on any other platform with the same version of "Vendor X Version Y Edition Z JRE". That's all you can safely say without a good amount more testing.
Since Java 1.2 I have never had any cross platform issues with Java. Java is so portable that Sun's NetBeans IDE will not only run totally unchanged on any Java 1.4 or above platform, it even runs totally unchanged on Java implementations from companies other than Sun's (BEA, IBM HP).
There are guidelines for writing portable apps (such as don't use com.sun.* or sun.* packages). They are easy to follow. If you choose to ignore these, and you have issues about different vendors JREs it is your fault.
I'm afraid that your points seem to me to be nothing but myths or FUD.
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ ref/SoftReference.html
It's been in the JDK for quite a while, and is exactly what you say is missing.
Mate, You're making clear that you don't use, or know much about, Java. Unlike, say, C++, choice of JVM and JRE is _not_ a mess of compatibility issues. It's backwards compatible and cross-platform compatible as all hell. Y Your claim that 'different JREs support different features' is just surreal. I've never seen any other language that is as good at backwards compatibility as Java (certainly not C++). Of course new features from Java 5.0 don't exist if someone runs in a JRE1.2. But the only way around that would be to freeze the language and never add a new feature ever. I spend a painful amount of time dealing with C++ issues with different compilers, I miss the ease of Java development.
This is really very good idea.
Bit it just illustrates the typical tradeoff between speed and memory.
Quick, but use twice the memory, or slow and don't use additional memory.
Is this algorithm in use in the JVM garbage collector or in other languages with garbage collection?
"if you didn't trust your compiler (or working toward multiple architectures) you could always use some compiler directives and some embedded asm"
:-)
You could also just compile the code, and dis-assemble the resulting object code to *know* what the compiler is generating. But, I guess its more fun to use imagination and conjecture to create points to debate.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
"Assume you are a contractor and all code is to be passed off to the internal development team afterwards"
You are doomed no matter what you do in this situation. NIH syndrome take over and you'll get blamed for everything anyway. When there is a problem the in house people will tell their PHB that whatever you did caused the problem. The PHB won't understand anything anyway.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
The C++ new and C malloc are not the same thing.
In C++ allocation is a fast business. Open up stdlib code and see what I mean.
In C, good applications use malloc carefully to minimize number of malloc calls.
Also, especially in C++ we AVOID dynamic allocation as many others have observed.
The author of the article is a mediocre programmer who does not know the nuances of his trade. I wonder if he could program in any other language than Java.
--exa--
Name one that isn't
I'll give you two. Ebay and Amazon.
(Operator Overloading being a prime example.)
... }
/**
Ugh, that's one of the things I don't miss from C++.
Look at java's "toString" function.. It's identical in inception to a 1'st class operator.. Something defined for all objects and can be overloaded. But Java documentation says NEVER USE THIS FOR PRODUCTION CODE. In other words, it's intended for debugging purposes.. Though "stringBuffer.toString()" does use this as it's main purpose, but that's forgivable since it's obvious that it's it's sole purpose.
Java could have had operator overloading if they merely implemented in the Object class something called:
Object.add(Object o);
likewise w/ sub, mul, div, mod, minus, index, invoke.
Those are the overloadables that I remember from c++ at any rate.
So I ask you. Why didn't they put them into the Object class? You could easily create a base interface for all your worker objects.
interface Mathable { E add(E); E sub(E);
Then you'd have identical functionality to operator overloading (except for 3'rd party libraries, but you could easily use bytecode enhancement even there).
So why don't we do this?
What the hell does "Object result = myInputStream.add(myGraphicalWidget);" produce?
It doesn't make any bloody sense? And that's the point. It makes sense to add NUMBERS, but not generic widgets. If it DOES make sense to add something to an object (being mutable) or to combine two objects and return a 3'rd (being immutable), then great.. Put them together accordingly.
And guess what:
Integer i = 5;
Double d = 7.0;
Long l = d % i;
Works just fine in java 5, thank you very much.
Otherwise, I'll keep my readibility of java over the following:
* comment, I don't remember what this does, but isn't it cool?
* I'm using operator overloading for no good reason
*/
void foo(BusinessObject1 bo1, BusinessObject2 bo2)
{
return bo1 + bo2[bo1(0)];
}
-Michael
Don't forget he's talking about java 1.4 and you're talking about java 1.5. One of the design features of 1.5 was to have the startup process pre-JIT'd specific to a target platform; though SUN only supports like 10 environments including Linux x86-32, Linux x86-64, windows and solaris.
So running a hello-world app is pretty darn fast in 1.5. But this doesn't do boo for a tomcat loading of 20 different app-contexts, each with 5 different explicitly defined servlets. And yeah, like you said, stock tomcat comes w/ like 6 application contexts including webdav and examples. My sys-admin never seems to remove them, so there's like a second or two of my startup time wasted.
-Michael
azureus (idle, no torrents running) takes 500mb of virtual memory and 100mb of real memory. when running, azureus is very sluggish. just like eclipse, by the way.
openoffice takes 100mb of virtual and 30mb of real memory.
what.the.fuck ?
But the allocation sequence isn't the bottleneck -- it's all about the actual garbage collection itself. GC can be costly in terms of cycles and, if you're unfortunate enough to be running in low physical memory, page faults. The reorganization of memory may improve application locality, but that may not be enough to buy back the performance penalty.
Rather than try to argue the case with hand-waving, my student Matthew Hertz and I performed experiments on an infrastructure that lets us replace garbage collection with malloc/free in Java programs so we can quantitiatively compare the cost of garbage collection. Our paper, to appear in OOPSLA 2005, shows that a good, generational copying garbage collector can match or slightly beat the performance of malloc/free -- but this requires 5X as much memory as the allocator. It's a classic space-time tradeoff. On the other hand, if you don't have enough RAM to hold the entire heap, though, garbage collection runs tens or hundreds of times slower.
--
Emery Berger
Asst. Professor, Dept. of Computer Science
University of Massachusetts Amherst
The C++ Corba bindings are incredibly obtuse. The "smart" pointers there are incredibly "unsmart", and the semantics of memory management is rather strange.
Upcasts are (conceptually?) new objects, meaning that you can free a CORBA_Object_ptr object, even if you have another *_ptr to a *::_narrow()'d version of it. In fact, you should, as that is the only way to guarantee the CORBA_Object ever gets freed! To keep some level of performance, while maintaining this obtuse semantics, even objects with plain pointers have to be reference-counter. Furthermore, when you (conceptually) deep copy an object with *::_duplicate(), in reality all you are doing is increasing a reference count. Thus, you will have to worry about reference counting whether you use CORBAs smart pointers or not! A further complication comes with out-parameters, which means that in addition to *_ptr, you will also need *_out for function out-arguments. All to keep the reference-counting (before we add smart pointers (the *_var types)) "sane".
True enough, using the *_var types make CORBA look almost sane, but they are optional (for performance reasons), and this complicates the CORBA C++ binding a lot. Actually, I'm yet to be convinced that the *_var types actually work sane enough, or get a clear explanation of when they work, because everything in the C++ binding remains nonintuitive. With typical implementations of smart pointers, such as e.g. boost::shared_ptr, new objects will have a reference count of zero, untill they are managed by a smart pointer, and when the reference count decreases to zero, the object will be free'd. Given the obtuse semantics described above, this is not possible with CORBA, as each new object will have a reference count of 1
Ok, maybe this explanation was as obtuse as the CORBA C++ bindings themselves, but it serves to illustrate my point. It would not be particularly hard to create a C++ CORBA binding that was as easy to use as Java's. It just happens that the CORBA C++ binding was designed by a committe that worried more about performance, multithreading, pre-standard-C++-compatibility, and the NIH-syndrome, than something clean and useful. IMHO, they should have left the micro-optimize-the-hell-out-of-it to the C binding, and left a clean C++ binding, but they didn't. Of course, all of this is in hindsight, at the time the bindings were created, I'm sure all the decisions made perfect sense!
... LOL. Comparing malloc to a memory manager is an early indicator of bias which I wouldn't point out if they had bothered to do so themselves (because it is valid to point out that C++ people tend to marginalize Java based upon performance out of hand and that's wrong.)
But, to compare oranges to oranges, my texture resource manager (written in C++) returns batches of pre-allocated memory (like the Java system mentioned in the article) in less than 6 machine instructions.
Loading...
I want my computer to respond as fast as possible every time and there is no comparison.
So it's a good thing you don't write web applications then. As this philosphy requires either using something like inetd to efficiently delegate web requests to your propiretary web servers, or using a thin shell script which does nothing but invoke OS applications like "sort" and "grep". Welcome to 1993.
The response time of a java application (w/ NIO support) is as fast as ANY c application (using UNIX select). Because the two applications are binarily equivalent. They both perform the same operations under the hood; just w/ different arrangements of code.
The difference is that java is much easier to debug extend, and overlay than a c application. Yes, PHP, ASP, VBScript, Perl-Mason, etc are more easy to extend/deploy than a servlet. BUt JSP's are a middle-ground; you can attach a person's "public_html" directory to your tomcat instance and thus provide arbitrary JSP support in just a useable environment as a mod_perl directory.
I assume that most people are complaining about java applications that are launched by the client.. But there's a reason why java applets are almost dead (replaced by flash). That's because script-kiddie web programmers want press-button-build application environments.. We call them RAD prototypers, but to each his/her own. Since Flash is easier to create, and prettier out of the box, flash overtook java.. But I don't hear ANYONE complaining about flash in this thread. Have you seen the load time of a flash app recently? It definitely isn't the bandwidth latency.
We accept this unreasonable load-time of flash because we think of it differently than say notepad or "vi". And that's precisely the point. We interact with these tools in a different way. Slowly desktop applications are being replaced by online services. Will the transfer be complete? Doubtful; not unless viruses have their way.
The irony is that the fastest growing application environment right now is javascript (e.g. AJAX). We've turned full circle back to the days GWBasic being the coolest thing on TV (think back to Richard Prior in Superman 3).
-Michael
So Java isn't slow anymore.
It just lacks a decent FOSS implementation.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Holy shit you're funny.
Did you seriously miss the irony of what you just said?
How dare programmers make me.. umm.. what's the word? "Upgrade" my hardware?
So memory is a religious point of conservation, but you're probably pissed that you can't afford that new 4000+ AMD-64x2????????? w.t.f?
What's the difference between needing more memory and more CPU speed?
People use to write in assembly inside of 64KB of RAM through a serial bus on 8bit processors.. They had to emulate real numbers for god's sake. We could still be doing this if we actually cared about keeping the consumers from having to upgrade their hardware.
The fact of the matter is that the cost of hardware is nothing compared to the cost of programming time.
And these days the biggest problem w/ programs are BUGS. So anything that reduces the amount of bugs is a GOOD thing for consumers. And if that means using a different programming language (like perl, python, java or C#) which doesn't produce core dumps or memory leaks (well, some better than others'), then hey, that's what the industry has learned.. The fact that you don't recognize the value of platform v.s. your existing platform doesn't mean that's going to disuade the developers.. They're using their language of choice for a reason.. Either they are super-proficient in their platform of choice and are able to regularly produce reliable code, OR they recognize that they have to outsource a lot of their work and they don't trust the quality of their hiries or they know that the level of complexity is going to overwhelm the managearial process. The result in all cases is the a appropriate platform is chosen given the current demographics of hardware.
So the reason you see 300Meg memory frames in IDE's like "idea" is because people that are willing to shell out $700 like myself for some software are willing to shell out a whoping $70 for the memory to run it. People that make little task-bar icons KNOW the demographic of their end user, so they don't create a tool that will consume 60Meg just to let them configure their graphics card.
-Michael
minor nit-pick.
Java and C/C++ are platform independent languages.
But Java isn't == C/C++. You'd have to say
Java/Swing/jboss == C++/KDE or C/GNOME
Then you find that C++/KDE and C/GNOME are NOT cross-platform. Or at least, supported on very few platforms.
We're not in CISC lab anymore, so we don't write little hello world apps that don't need a UI. When you write a C++ these days, you're talking about the full enchilada.. The end-to-end app.. And I'm not aware of non-geek tools that dont' require something more than a CLI. And I know of very few UI's that are cross-platform.
THIS is where Java excels. Of course due to market conditions, Java hasn't taken off in this areana.. The horrific HTML + CSS + javascript world has taken Java's place here... But we're back to the early 80's days of C where you couldn't recompile the same app on a different platform (e.g. I.E. only or firefox only apps).
-Michael
Not seeing how a card shuffling game is a good benchmark. Nor am I seeing how something that runs in less than a minute is a good benchmark.
That's like the classic "how fast can I copy memory" benchmark which isn't even a good memory benchmark or the adding two numbers a billion times.
-Michael
The idea of a garbage collector for C has been around for a lot longer than 11 years.
Hans-Juergen Boehm and Mark Weiser, "Garbage collection in an uncooperative environment", Software Practice and Experience, 18, 807-820 (1988).
"Weiser experimented with a special version of the collector for tracing storage leaks; typically, the collector does a better job than programmers."
Here's an even earlier reference from 1984 to a garbage collector for C, in a paper by Bjarne Stroustrup.
Newsgroups: net.lang.c
From: mark@umcp-cs.UUCP
Date: Sat, 2-Jun-84 21:37:41 EDT
Local: Sat, Jun 2 1984 6:37 pm
Subject: garbage collection in C
A footnote on page 11 of the AT&T Bell Labs Memo 109 entitled Data Abstraction in C, by Bjarne Stroustrup, says that a garbage collector version of the malloc function exists. Any one else ever heard of this? Know where I can get one?
--
Spoken: Mark Weiser ARPA: mark@maryland
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
-Don
Take a look and feel free: http://www.PieMenu.com
I'm not a hard-core Java or C programmer, myself, so maybe there are fine technical details that I'm not privy to. But it seems to me that the primary lesson of the "Java is slow legend" is that proves the truth of the old saying:
You never get a second chance to make a first impression.
When Java first came out in the mid-90s, programs written in it ran sloooowly. This was especially true for the types of client-facing programs that people would notice were written in Java (things like applets).
Today the JVM has been massively improved, hardware has gotten a couple of orders of magnitude faster, and Java programs aren't slow anymore. But people still think "Java == slow".
Why? Because that was their first impression of Java. And it will take many years of contrary experience to overcome the power of that first impression.
From my layman's point of view, Java has really only seemed to be adequate performance-wise for a few years now (I remember Eclipse being the first Java app I saw that really felt as snappy as a native app, and it launched in what, 2001?). So a lot of people still probably have a lot of hours they need to log working with modern Java apps before the "myth" gets completely dispelled...
Read my blog.
I'm sick of apps that show splash screen for 3 seconds or more. And programmers who insert timing delays so I can admire that fucking splash for the 1000th time should be shot...in the face.
"The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions"
While that sounds very good, they don't add that there is overhead introduced in the form of reference tracking in managed-style languages. When each variable loses scope, its reference count is decremented. That operation, while not hugely impactful, is not entirely free. It takes at least a single testandset instruction. So if you are managing a large number of references to that object, you are shifting the burden to other places in the code.
Nothing is free... you don't get 'bytecode portability' for free over native instructions. You can't compare a managed memory model new to a unmanaged memory model new because they aren't doing the same thing. You also can't compare program environments without also measuring startup and shutdown time.
The bottom line for Java and CSharp is that byte code doesn't come for free...and modern C/C++ developers use object pools, not malloc/free. You might new an object quicker in Java, but if you compare overall execution times the extra cycles shake out in other places. But to compare an object oriented allocator to a general purpose byte allocator is a bit silly.
Just remember...if bytecode were the fastest way to execute instructions on the processor, the processor would work with bytecode. But modern JVM's convert bytecode into native instructions, so they'll always be behind in performance no matter how optimized their memory management. Yes, simple repeated malloc/frees can be shown to be slow...but thats why concepts like reusable pooled objects came about. Thats why there are about 100 different malloc libraries, each claiming to be the fastest at some memory usage tradeoff.
I just don't buy the BS that Java is as fast as native languages...even in memory management. If java can manage its memory quickly, so can I. Java isn't written in Java, now is it?
I'm more pissed that programmers can't figure out how to display a few widgets on my screen without needing 700mhz+ of CPU power to render them!
Look at program features vs code size, it is NOT an even balance at all. Heck MS had that problem with Office XP, minimal new feature set, HUGE performance drop. Oops. Thankfully they cleaned their code up and released Office 2003.
As for bugs, maybe if programmers didn't suck so much arse now days... you know, if they were made to actually think about their code rather than using the compiler as a debugger...
When trying to squeeze every last byte (or bit!) of efficiency out of a code segment, that chunk of code is going to be looked over far more carefully than some OO class that is written once than just instantiated by people ever-after. More time is going to be spent thinking about the algorithms in use, how do they work, how reliable are they.
There is a reason why the old mainframes were trusted to run so many facets of our lives, but so few (technical or non-technical types) are willing to trust modern OSs to run things like, say, airplanes.
There was also a reason that Ada was used for a lot of aircraft programming, it is HORRIBLE for the programmer to use it, very very painful. Declaring a pointer to a variable takes 3 lines of code! (well you can squeeze it into two IIRC), compare this to the C derived languages, where, excepting Java, you have pointers sometimes with just one character.
Implementing polymorphic objects in it is a pain, it made you think about exactly what you were doing VERY carefully, heck everything about Ada was like that.
So of course the programming community killed it, after all, who wants to program in a language that is just "safe"?
Then again I don't have much room to stand here, my favorite language is C, specifically because the compiler lets me pass darn nearly anything in as valid code (so long as the braces match up and I got the semicolons in place...
Programmers have lost sight of eloquence; tell me, why are you programming something in 100 megs when it could take, umm, A FEW HUNDRED KILOBYTES.
Are modern programmers (myself included....) so bad that we need literally hundreds of megabytes of overhead to protect our dumb ass's from ourselves? Are we so out of touch with the machines we proclaim dominance over (or at least a good working relationship with) that we need to abstract ourselves 838,860,800 Bits away from our machines?
Need help treating your acne? Come here!
You really have to love languages where a invocation "suggests" that the method "expend effort"
Good effort! You did your best, son! Good hussle out there. It's too bad you're still gobbling up 100MB of RAM, but don't worry tiger, we'll get 'em next time.
The GUI is the one big problem with Java. Swing is a dog, despite being a considerable improvement over AWT (which is a dessicated undead dog from the paleozoic). Azureus is pretty good in general for the simple reason that it is very minimalistic with the GUI. It keeps things simple, and so it doesn't suffer.
Don't forget he's talking about java 1.4 and you're talking about java 1.5. One of the design features of 1.5 was to have the startup process pre-JIT'd specific to a target platform
There is no pre-JITing as far as I can tell from the documentation. The reason for the faster start-up is that system classes are cached (not compiled) in a way that allows much faster loading.
I tried the same tomcat startup on Java 1.4.2_04. Instead of 5 seconds (for 1.5.0) it took 7.
it uses SWT.
JIT compiles the Java bytecode to native machine code -- which is, at least theoretically, potentially faster code than a C or C++ compiler can generate because it has more information. Sure, you could say that you could just implement a JVM/JIT on top of C/C++ for every program you write and get the same performance, but that's just silly.
HAND.
Google IS running Java VMs. Java powers Gmail and Blogger, for example.
Those rules seem inflexible to me, and sound like rules a professor would tell his students when he is tired of reading their unreadable attempts at optimization. Optimization is really useful if you need your program to go faster. Of course, if you don't know how to optimize, you will have trouble. Here is a very good page by Paul Hsieh about optimization:
http://www.azillionmonkeys.com/qed/optimize.html
Qxe4
I don't see the problem
Suppose I have a class name and I create a subclass place-name by adding a slot for a location. Meanwhile I need colours, both for my paints and my objects so I create a colour. Finally a create a class coloured-place-namefor named things in that are put in places and have colours, by multiple-inheritance, taking first place-name and then colour.
At this point I have an inheritance ambiguity. Obviously place-name comes first, but what next, name or colour? What I don't see is why I should care.
It is only going to matter if I have a method, act, defined for both name and colour. But how could that happen? I'm only using multiple inheritance because all three of place-name,coloured-place-name, and colour make sense. If only two of them made sense I would use single inheritance. So the meanings of act on the two classes are orthogonal, I don't want one shadowing the other.
We really have a name clash, and need to sort out our names. Perhaps act on name should be speak, and act on colour should be paint
OK the inheritance graph isn't totally ordered, but each method is only defined on a subset and, for any particular method, its subset will be totally ordered. So I cannot see a problem that actually matters in practice
We have never encountered many problems with JNI interfaces, perhaps simply because we choose to keep this kind of interface as simple as possible and do not actually do it that often. Certainly I find it much less troublesome and time-consuming to generate and test a JNI interface than most others; although that may be largely down to experience.
I remember that we once had one server-side JNI call we had enormous trouble with, making us try all kinds of ways around it, including testing three or four different VMs. Some were indeed more stable than others, but we finally discovered that it was our own fault because our JNI implementation had a bug in its memory management. We fixed that and the system became capable of running for indefinite time (i.e. until the hardware fails or we have a power cut) without human intervention, one any Sun JRE after 1.3. Actually, I recently saw that it still has an UTF string release bug in it, but apparently this doesn't cause any trouble (yet).
Sometimes the system architecture calls for layering multiple interfaces -- as in PL/SQL calling Java calling C++ -- and that can be tricky, because you have to respect all the different 'boundary conditions'. But on the whole JNI is much better than some other interfacing technologies I have seen; especially the ones designed for specific systems.
I totally agree, someone should really rewrite Firefox. I have no idea what it is written in now but it really sounds like that java you mention.
An additional comment: One reason I like to work in Java is that some of my software is single-user software in the most literal sense: There is one person using them, besides myself.
Writing 15,000 lines of fairly complicated code for a single user, or four times as much for a dozen users, can make sense; although probably most software companies would disagree. However, I naturally want to do it in a language that offers rich libraries and is easy to troubleshoot. Java fits the bill almost perfectly; in many other languages I would be spending twice as much time on the same project.
I can perfectly understand that people who write application servers for eBay, or office applications for an user base of millions, feel that Java is not the best choice for it. However, the economics of that are entirely different.
I think that if you have to write an application that is too complicated or demanding for a script language, but also need to keep the investment in time and resources down, Java, mixed with a little C++ where necessary, is close to ideal. Before Java, I used a mix of Tcl/Tk and C++, and that was OK, but not great.
In Java, the auto garbage collection is as good as Perl's
It's just that Perl doesn't have GC, but shoddy reference counting, which is easily confused by cyclic references. If Java is as "good" as Perl there, that's not the best of advertisements.
Your stack pointer in inside the chip in a special dedicated register.
When a function is called it's stack frame is created to store the return address and storage for any registers that will be changed. It is allocated by simply subtracting a number from the stack register.
Since its always allocated and always freed, to allocate some space for your automatics costs zero cycles - you simply subtract a bigger number from the stack pointer register.
When you have something on a stack frame it is referenced using the stack pointer, so for example
int foo()
{
int y = 100;
}
The variable y is actually some offset plus the stack pointer, the offset is coded into the program instruction because it is fixed.
For example it may be the variable y will be something like (4+sp) and int y=100, becomes a "move 100 -> 4+sp".
Notice that you did not need to store the address of the block, because the variable is always at a fixed offset from the stack pointer.
Now consider the case of an allocated block, the address of that block has to be stored somewhere, normally IN THE STACK FRAME! Even if you made a really small program and the compiler was able to keep it in a register, because the register isn't dedicated to the purpose, the compiler would still have to save and restore it as part of the function entry.
Please step back from your position and see that your position is incorrect.
Well, let's see. My *bank* (TD Canada Trust) uses it for their online banking. It's never been anything but fast for me.
I also work on my company's team developing our online applications, all in Java on the server side. Whenever we'd had a performance issue, it'd been traced to bad code, not the JVM. But our modest hardware is supporting users from all over the country, and our customers are the medium-large (+ gov't) businesses, and we have no trouble supporting them with this setup. Now we don't use JSP (I vetoed that approach because it doesn't enforce MVC well enough for my liking), but rather a Servlets+Velocity templates approach works well for us.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
Thanks for your thoughts.
Programmers have lost sight of eloquence; tell me, why are you programming something in 100 megs when it could take, umm, A FEW HUNDRED KILOBYTES.
Are modern programmers (myself included....) so bad that we need literally hundreds of megabytes of overhead to protect our dumb ass's from ourselves? Are we so out of touch with the machines we proclaim dominance over (or at least a good working relationship with) that we need to abstract ourselves 838,860,800 Bits away from our machines?
This is a legitimate question.. The answer is that because anything can pass in "c" for code, it is impossible to validate and anylize the code correctly.. The best you can do is use heuristics. If you have, say a pointer to a function being passed around, and god forbid that you convert it to a void (sym void) or whatever the proper syntax was (I forget).. Then your analysis tools can not extend beyond that point.
Perl and other symbolic languages have the same problem. C++ is a little better, but you can still write C code in C++, so the tool isn't fool proof.
Why do I care? Because of the refactoring capabilities of modern programming IDE's. (Eclipse/Idea). I can perform a "safe delete" on a function or variable because the code can be anylized and determine precisely if anybody actually uses it (though reflection/aspected/bytecode-modification does put a tiny wrinkle on that). As a backup, to handle reflective invocations which would cause run-time failure, I can extend the usage-search to include strings in xml files or JSP files. Granted, this doesn't resolve dynamically constructed field names '"get" + methodName'. Renaming classes, renaming methods, renaming variables, fields, etc, are important for refactoring and the migration of code. When you work on large collaborative environments you have two options.. Maintain backward compatibility (explicitly defining cut-off points), or refactoring all code that touches your API. W/ refactoring tools, this is a mouse-click away.
Moreover, my IDE can tell me if code is garunteed to generate a null pointer.. If nothing in the associated libraries can possibly return a null pointer (determined by literally searching for all sub-classes found in any 3'rd party library and anylizing their byte-code), then the editor knows that an immediate dereference after acquiring a value from a method call is safe.. If not, my IDE highlights the line as a probable error. That is absolutely impossible in a c/binary set of external libraries. Especially shared libraries.
Now it's technically possible to deploy a Java application w/ a different set of libraries (especially if up upgrade those libraries after compilation), so it's not fool proof. But if you're interfacing w/ 3'rd party libraries you should probably have a rudimentary set of parameter/result validation code. But w/in your own library this technique is very powerful.
Another incredibly useful tool is hack-removal.. Packages should minimize inter-package communication (and thereby inter-package dependency). W/ Analysis tools you can graphically determine the degree of inter-package relationship. And on a case by case basis determine if the design should be refactorered to remove the reference/dependency/etc. Ideally you shouldn't have bi-directional dependency. As you're coding, it's entirely likely that you'll make these bidirectional associations out of convinience or lack of consideration. But a post-facto code analysis is instrumental in weeding out these bad design issues.
While this is possible to a certain degree in C, and a larger degree in C++, it is hard to do, and I've found few tools that do this in a reasonable manner. "source_navigator" by RedHat was ok, but wasn't very easy to use (at least w/ my editors of choice).
The key is that "it compiles ship it" is less of a joke in Java than almost any other language. And THIS is why companies make use of Java for enterprise applications.
-Michael
But not significantly so that most people that today uses Java feels any need to leave for C#, unless it's a very personal preference.
"I think this line is mostly filler"
Look at java's "toString" function.. It's identical in inception to a 1'st class operator
... } Then you'd have identical functionality to operator overloading ...except for the whole operator overloading bit. Again, review above. Operator overloading would let me write ...
Um, except for the whole operator part.
Something defined for all objects and can be overloaded
Operators needn't be defined for all objects. In C++,
vector<int> a, b;
a = a + b
doesn't work. That's because + isn't defined on vectors.
Java could have had operator overloading if they merely implemented in the Object class something called Object.add(Object o);
No, then there'd be a method called add. Java could have had operator overloading if you could write a + b if a had an add method that could take b as a parameter. You should review what operator overloading is. It provides an alternate syntax for method calls; a + b gets translated to a.operator+(b). (Assuming operator+ is a member function and not a free function yadda yadda yadda.)
You could easily create a base interface for all your worker objects. interface Mathable { E add(E); E sub(E);
Complex a, b, c;
a = b + c;
The bottom line:
Operator overloading is a tool. It can be misused. There's even a proposal before the C++0x standard committee to allow the following:
vector<int> v;
v += 1, 2, 3;
to add 1 2 and 3 to the vector. This is (IMO) an abuse of OO. It doesn't make sense. Your example of giving generic widgets an add method doesn't make sense. So it shouldn't be done.
But if I'm writing a complex number class, or a rational number class, I sure as heck would like to be able to say a + b instead of a.add(b), especially as the latter to me seems more like a += b than returning the sum without a side effect.
It also allows a lot of other nice things. I'm a fan of cout in C++. I think cout << a << b; is a lot more readable than out.print(a); out.print(b);. You can't write an equivalent to printf in Java because you can't have a variable length parameter list.
Finally, admittedly, operator overloading in Java would be little more than syntactic sugar. However, in C++ it's very important to generic programming. Operator overloading allows you to write, for instance, the valarray template class so that it will work with any data type. Or std::max:
template <typename T>
T max(T const & a, T const & b)
{
return ( a>b ? a : b);
}
Without operator overloading, you could write that and have it work for primitive types but not classes or you could replace the > with a method call and have it work for class types but not primitives, but you couldn't have it both ways.
(Actually, that's not true. You could combine the two with some auxilary functions and template total specialization, but does that sound like fun? No way, and you'd wind up with a lot more duplicated code.)
You could combine the two with some auxilary functions and template total specialization
Partial, not total. My bad.
Oh yeah, and, for instance, VC++ hasn't supported that until the latest version. Good luck writing a proper max function without.
I am talking about all 3 BSDs, complete unix operating systems, kernel and userland. They use CVS to maintain their code, cvs commits are sent to a mailing list so people can see what's going on. I get those messages. Memory leaks are very few and far between, despite development being very active, all the time.
Quite frankly I wrote a (thread-safe when necessary) reference counting handle template for C++ and so I don't need a garbage collector in the kind of applications that have non-trivial heap profiles.
MEANWHILE I have useful destructors instead of "maybe later" finialize methods. Fo _me_ the non-starter feature of java is that I have to reference count manually _on_ _top_ _of_ the garbage collector if I want to have my objects perform end-of-life actions when they move out of reference. In C++ I can put close-and-clean functions in a destructor, in Java I have to manually close the object "when I know it's ready" which is the same amount of work as freeing an allocation "when I know it's ready".
Tools have to match jobs. I do use Java on occasion, but only for toy-like applications that don't have to survive very long.
One of my company's (C++) products was written solely by myself (to version 1.1, then was handed over to a maintainer and feature crew) has multi-month runtime requirements that it meets quite nicely. I put the heap issues to rest so early in the development cycle. The application _could_ have been written in java, except the fast recovery (etc) features that a proper distructor give me would have been impossible in Java. In C++ I throw an exception and the stack unwinds and I _KNOW_ with certanty that I wont have to self-contend with any object was abandoned by the unwinding. The destructors were invoked and completed in proper context and in unwinding-order. Java simply _doesn't_ have the ability to do that.
An example you ask? Create a class that destructively accesses/updates a file at close time (lock files, db-journals, and state maps for instance). Now use a deterministic file naming system, so that thread X uses file name X. Now throw an exception from a point where the file is open, and catch that exception in a scope outside the file object's scope and then re-enter the scope after catching the exception...
OK, in java you _could_ catch the exception at the scope where the file was allocated, close the file, and then re-throw the exception. But then you need to do the same thing for each scope-of-object for each object that is dependent on the file. Which will only work if you refrain from building complex object-structures on the heap (q.v. trees, etc). Well unless you... (recurse as necessary)...
A reference counted handle object with proper destructors will traverse complex heap structures in depth first order, so objects can be written in closure (see "invariants" in OOD). Java finialize behavior only works in breadth first order, so the objects can and do not have closure without the programmer doing manual recursive cleanups.
So the garbage collection time can be as fast as you please but there are a non-trivial set of programs that simply will not function in java without paying the "clean up cost" twice. Once by hand, and once again to discard the memory. The cost is paid in complexity and dependence resolution, none of which is "easier" than heap management and all of which requires the same attention to, and possesses the same semantic pitfalls as, faulty heap management.
Software, and by extension, languages that help you when you _don't_ want the help are (IMHO) more harmful than languages that don't help you when you do.
It's "better" to have an additive environment, where you put in the features you want and need, then a subtractive environment where you ignore the features you don't need and _hope_ that they don't do you harm. (q.v. every object in java is a mutex but if you dont need it to be the execution environment... what exactly? just pretends it isn't?)
Not that much! remember, baby steps.
"I think this line is mostly filler"
Thank you, that makes a lot more sense than "because we want to and it is easier for us", the excuse I hear so often from so many programmers.
;) ), this mostly applies for cases when you do not have the original source code correct?
If I am understanding correctly (realize that Universities don't even seem to go into JUnit and such, there seems to be some sorta of stigma attached to practical learning.
Need help treating your acne? Come here!
But I was having login problems at work...
/sigh
ah, technology...
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
It's certainly older than my Athlon 4800+, and it's older than G5's they sell today. I didn't say "old", I said "older." English, whadda language!
True.
No, you said "older". Go re-read:
(emphasis mine)
What a language indeed!
Is Capitalism Good for the Poor?
Um, except for the whole operator part. .. } ... args) ... arrgs) ... comparables)
Operators are pure syntactic sugar. There are an enormous number of meta-languages around java; bean-sh, groovy and others which alter the syntactic sugar.
Moreoever, Java has demonstrated that best-practices eventually get syntactic sugar enhancements in later versions.
Look at auto-boxing, for example.
Integer bar(..) {
int foo(..) { return bar(..); }
int Integer are auto converted as pure syntactic sugar.
So now
Map map;
map.put(1 + map.get(key));
is feasible (increment value in map).
To favor your point and disfavor mine, "toString" IS an operator in Java.. Namely it overloads the "+" symbol.
Integer i;
Bar b;
String s;
File f;
return s + i + b + f;
This is syntactic sugar for:
return new StringBuffer().append(s).append(i).append(b.toStri ng()).append(f.toString()).toString();
Probably just calls toString on s and i as well; it's compiler specific.
---
The point is that operators are visual queues.. They can be nice, but they have to be balanced against abuse.
Java specifically looked at the level of operator overloading available to C++ and decided against them, with the one exception of defining the plus operator.
No, then there'd be a method called add.
Again, syntactic sugar. Functionally identical. The two forms of operation are dramatically different:
printf("[%i]\n", val);
cout.print(val.toString());
But the latter is functionally identical to "cout I sure as heck would like to be able to say a + b instead of a.add(b), especially as the latter to me seems more like a += b than returning the sum without a side effect.
Agreed. Java isn't very consistent in it's core API method naming conventions. map.add(.) mutates the object which stringBuffer.add(.) returns an immutable value-object. This is SUNs fault and hasn't been corrected yet. Though Java-Bean specification does a very nice job of this with get/set prefixes though "verb" methods are a mixed bag. Same w/ any language.
You can't write an equivalent to printf in Java because you can't have a variable length parameter list.
Sorry, dated.
System.out.printf("[%i,%s]\n",var1, var2);
has worked since verion 1.5. In fact you have an i18n version:
Locale l;
System.out.printf(l, "%i", var);
You now have a much more powerful version of the "..." parameter.. Namely type safe:
void foo(Integer
void bar(Foo
PLUS the multi-parameter autoboxes arrays, multi-parameters, and collections.
Integer[] ints;
foo(ints);
foo(1,2,new Integer(3));
Set sints;
foo(sints);
all works just fine.
std::max
class Util
{
public static Number max(Comparable
{
if (comparables == null || comparables.length == 0)
{ throw new InvalidArgumentException("empty set"); }
Comparable maxComparable = comparables[0];
for (Comparable c : comparables)
{
if (maxComparable.compareTo(c) > 0) { maxComparable = c; }
}
return maxComparable;
}
Done! And thanks to auto-boxing, works with ALL primitives.. And even if it didn't.. If you were doing this in Java 1.4
Util.max(new Character(c1), new Character(c2));
Thanks to the foresite of java 1.0, the need for generics has not existed until only recently.. And that was only for type-safety, not for generalization.. Namely all collections take generic Objects.. Something that was severely lacking in C++ (due to multi-inheretance). Any specific capabilities use interfaces or interface markers (like clone or serializable).
Moreo
-Michael
We just removed everything on that list that we didn't need. I think the only thing we kept was the JCE jar. It all compresses down to about 18MB (Nullsoft installer, LZMA compression). Also, you can put any of your jars into jre/lib/ext, and the VM will pick them up automatically without you having to add them to the classpath.
Operators are pure syntactic sugar.
Yes, I know. You'll notice I said that.
But I'd argue they are an important bit of syntactic sugar for writing nice code. Again, a+b (to me) is A LOT nicer than add(a,b).
Java isn't very consistent in it's core API method naming conventions. map.add(.) mutates the object which stringBuffer.add(.) returns an immutable value-object. This is SUNs fault and hasn't been corrected yet.
Not to mention the ways of getting the size of a collection. Collections have a size() method, Strings a length() method, and arrays a length read-only property. Go consistancy!
Sorry, dated.
System.out.printf("[%i,%s]\n",var1, var2);
has worked since verion 1.5
Very interesting. I don't think I ran into that when I was reading about 1.5. Thanks for the correction.
(My experience with Java has been exclusively with 1.4. I've now done two projects with it; one was started before Java 5 was released, and one was written for a platform that hasn't yet had the Java 5 SDK ported to it. I have seen some things about 1.5 and have liked what I see, but I wasn't aware of this.)
Done! And thanks to auto-boxing, works with ALL primitives
See above with my (lack of) Java 5 experience. I was aware of autoboxing, I just didn't put it together to be used in that way.
Thanks to the foresite of java 1.0, the need for generics has not existed until only recently
In what manner? I haven't seen any benefits besides the lack of a need now to cast.
(And I'd say that it WAS needed before, because having to cast from object on every get or whatever leads to sloppy code and errors that can't be detected until runtime if you screw up the type. It was just that Sun took their time to get the implementation right and probably do higher priority things first.)
Something that was severely lacking in C++ (due to multi-inheretance)
Multiple inheritance shouldn't have anything to do with it.
(Oh, and MI is another thing I miss in Java. I have almost never used it, but when I have it's been a Godsend. I'd have really liked to have had it for my second project; there was one place it would have saved a couple hundred lines at least of duplicated code. (It wouldn't have been a good use from an OO design standpoint, but I'm reminded of the error-handling idiom of using gotos in the Linux kernel. Not good from an acedemic standpoint, but it gives much cleaner code and is good from an engineering standpoint.)
Any specific capabilities use interfaces or interface markers (like clone or serializable)
Stuff that C++ mostly doesn't need because of templates.
Moreover, the Collections is INSANELY useful.. Pretty much providing an open-source hand-book to almost all computer science class problems. The bane to any CISC teacher. sort, binarySearch, shuffle, min,max, reverse and others.
Most of which is in the STL. The only major thing in Java.Util that's missing (which, admittedly, is a pretty big omission) is a hash table. Other things that are missing (e.g. regular expressions, threads) are available in other free, high quality libraries like Boost. (With a BSD style, not copyleft license.)
Sorry, my opinion is that Java is one of the most pleasant languages to program in for just about any sized project. I grew up on C++ and C.. Later in perl
To each his own. I don't really like programming in Java because I feel like the language is boxing me in, preventing me from doing things that I think I should be able to coming from a C++ background.
It's getting better, but I still prefer C++.
(I'm not trying to dis you by the way, it really is a personal preference.)
Similarily, I think the debate over operator overloading comes down to preference. I think the readibility benefits gained outweigh the potential for abuse. You feel that the problems of abuse outweigh the readability benefits. Whatever.
Si it's time for you to read about UTF-8:
First I noticed that some of my code was cut-off due to less-thans.. bugger.
Thanks to the foresite of java 1.0, the need for generics has not existed until only recently
In what manner? I haven't seen any benefits besides the lack of a need now to cast.
Well, I admit that Java 1.5 generics was a more of a show than a real implementation. The only thing it does is generate really wierd exceptions when you pull from a generalized class. For example.
List foo = new ArrayList();
foo.add(null);
List bar = foo;
int 5 = bar.get(0);
I've scratched my head on that one. Hibernate can return List but contain a single row w/ a null.. So I have to perform
if (foo == null || foo.get(0) == null) { return 0; }
return ((Integer)foo.get(0));
The Collections class has lots of type-checkers, but they ONLY work if you are the one that instantes the collections.. I haven't found any 3'rd party tools which do post-facto validation of type-safety in a collection. I've had to roll my own.
Other than this specific issue w/ accessing external libraries, I really love the type-safety enforcement w/in my own internal libraries thanks to generics.
Something that was severely lacking in C++ (due to multi-inheretance)
Multiple inheritance shouldn't have anything to do with it.
Shouldn't, but due to performance, does. Perl makes use of hierarchical arrays of package names to implement MI. This can be an analysis nightmare as you have to know the order in which the super-classes were defined (in a subclass) in order to determine which conflicting super method will be invoked. It's also a performance nightmare. Method calls become linear nested traversals of array-lists. Additionally most implementations of OO in Perl make use of a hash-map.. Essentially all fields are virtual (potentially conflicting between alternate class definitions).
In C++ you have to fiddle w/ virtual inheretance and can't make arbitrary inheretance.. If you get a 3'rd party library, it's possible that you physically can't composite multiple classes (due to collisions and lack of declared virtual inheretance). The requirement to declare a method as virtual is both a positive and negative.. Great for explicit definition of an OO heirarchy, horrible for extending classes beyond what the original author conceived (e.g. 3'rd party libraries). I don't recall if C++ has the equivalent of Java's final modifier.. I've found it to be incredibly frustrating (in terms of preventing prevention of code-reuse). In Java "final" is useless except on 1'st class objects like "String" which have JVM optimizations. A good JVM can determine the "final" attribute at runtime based on whether anything actually overloads the method or not. In C++ such an optimization isn't possible, so there is a serious performance advantage to not declaring a method as virtual. It's the difference between a c-style direct function call and an indirection-table lookup (or two).
In Java, MI is ommited purely for OO elegance. Thanks to heavy use of interfaces (and runtime optimizations of interfaces into static method invocations where possible) you get all the advantages of MI w/ none of the complexities and limitations. The ONLY thing MI provides (and you correctly pointed out) is the lack of code-reuse. BUT, this is actually a blessing in disguise. Take the following example:
class BaseWebPage
{
Foo utilityA(...);
Bar utilityB(...);
abstract void drawPage(...);
}
OO here is purely for utilitarian purposes. But how about
class PageA
{
UtilityA utilityA; void setUtilityA(UtilityA ua) { utilityA = ua; }
UtilityB utilityB; void setUtilityB(UtilityB ub) { utilityB = ub; }
void drawPage(...) { utilityA.doA(...); utilityB.doB(...); }
}
This latter code is MORE OO than the foremore. Here you can swap out what utility A actually is.
-Michael
Yes, you are absolutely right that memory leaks and pointer problems in C suck, and that dealing with them is a colossal waste of time. And Java's garbage collection is, in some ways, better than Perl's.
However, Java is neither the only, nor the first, nor the best language to offer garbage collection and runtime safety. Java's type system sucks, its implementation of generics is awful, its native code interface is slow and cumbersome, its libraries are bloated and saddled by backwards compatibility issues, and the platform is being designed by huge committees of self-appointed experts.
Do yourself a favor and use some other language. There are many choices; my personal favorites are Python, C#, and OCaml.
The only thing it does is generate really wierd exceptions when you pull from a generalized class. For example.
... you get all the advantages ... . The ONLY thing MI provides (and you correctly pointed out) is the lack of code-reuse.
;-)
In Java's defense here, I don't see any real way around that. Not allowing you to implicitly cast an Integer to an int breaks the autounboxing bit of sugar, and prohibiting you from putting null in a container is just wrong.
I'd say that Java has the best option here, with the possible exception that it might be nice to have a little nicer exception type or message.
In C++ you have to fiddle w/ virtual inheretance and can't make arbitrary inheretance.. If you get a 3'rd party library, it's possible that you physically can't composite multiple classes (due to collisions and lack of declared virtual inheretance).
Is this what you're talking about:
struct B1 { int foo() { return 0; } };
struct B2 { int foo() { return 1; } };
struct D: public B1, public B2 {};
Because if it is, that doesn't really present a problem; you just have to specify which foo D should use.
The requirement to declare a method as virtual is both a positive and negative.. Great for explicit definition of an OO heirarchy
I think from a pure OO standpoint, I like methods to be implicitly virtual rather than implicitly non-virtual, but that's just me.
I don't recall if C++ has the equivalent of Java's final modifier
No, it doesn't.
But, if you have a class that isn't in a heirarchy of your own, you can go along ways toward preventing effective reuse by making a public, non-virtual constructor. Deriving from such a class can open up a can of worms for anyone who does it without being careful.
Thanks to heavy use of interfaces
Seems you contradict yourself there a bit.
Also, it can in some sense lead to cleaner code and cleaner design. Look at all the places in Java where there is a class you can extend to get some functionality OR an interface you can use in case you're subclassing something else. Like if you want to make a thread, you can subclass Thread or implement Runnable. If you're writing Swing you can extend DefaultWindowListener or implement WindowListener. (I don't know if those are actual names, but you get the idea.)
Finally, the prevention of code-reuse can, in some cases, be a decent drawback.
I think I already mentioned this, but MI prevents you from defining a top-level Object class.
And again, I don't understand why. You might have to sort out if it inherits virtually or not (though if the object doesn't have state I think that's a meaningless bit anyway!), but I see no reason it can't be done.
If you want to have a function that accepts any type of data, you are forced to accept a void*.
In what case would you want to do this? I can only think of two. The first is if you're writing something like the sort of thread start methods you see in some languages where you can pass a void* parameter with information for the thread about what it should do. (Java doesn't do this for threads as you can store stuff in the Thread object's fields beforehand, but such a situation is certainly concievable.) The second is if you were writing something to deal with, say, JavaBeans and were using the reflection API to figure out what the methods are in the object.
In the former case, Java's method is admittedly a lot superior because it typechecks instead of causing massive explosions. In the latter situation you just flat out can't write something like that in C++ because of the lack of reflection.
(And reflection is perhaps at the top of my wish list for C++.)
I'm very confused as to how you could say this.. java.util.Hashtable is a java 1.0 feature.
Sorry, I worded my original statement pretty poorly. It should have said
sulam> I didn't say "old", I said "older." English, whadda language! MFN> No, you said "older". Go re-read: Violent agreement? I said I said "older". You quote me saying I said "older." What am I supposed to be disagreeing with? Why are you telling me what I said? ;)
Dammit... OK, you got me on that one. :P
I'm going to go back to preschool and learn to read now...
Is Capitalism Good for the Poor?
I'm so sick of this recurring "Java is as fast (or faster!) than C++" absolute nonsense. Java is provably slower than C (in other words, Java has overhead as compared to C). Consider an operation X.
... if you're an idiot.
My C++ program, doing operation X, has to perform the following actions, at the machine level:
X
An equivalent Java program, doing operation X, must perform the following actions at the machine level:
**A Bunch Of Stuff**
X
The part varies depending on the case. Heck, sometimes it's not even there (JIT and all that). But it is there, and it's not free.
Honestly, this is the most brutally, painfully, hit-you-over-the-head-with-a-sledgehammer obvious thing ever.
Yes, a given Java program can be much faster than a given C++ program... a given shell script can be much faster than an assembly program, too.
Clearly this implies that shell scripts are faster than hand coded assembly!