You JVM advocates always throw out that "faster than C" line. I know, I know, you can prove it, too, using one of your many highly-controlled microbenchmarks that have absolutely no relevance in the real world.
I don't think anyone truly knowledgeable about the subject is going to argue that. Java wasn't designed to be a better C, it was designed to be a better C++. And in many ways it truly is, see my post above.
I know, I know, bytecode and JIT compilation allows for CPU-specific optimizations to be done. That's great, except that even the best JVMs today don't do that.
Actually, today *any* semi decent virtual machine will be peforming these optimizations. That's why you see all the benchmarks showing Sun's HotSpot jvm performing so competitively with statically compiled code, even outperforming it in various situations. The cool thing about virtual machines isn't that they can "allow for CPU-specific optimizations," but that they can perform all types application specific optimization at runtime. For example, a virtual machine can analyze the current flow graph and use a technique called escape analysis to allocate data on the stack, even for data where it wouldn't be practical or possible in a statically compiled application. As I mentioned in the above post, vtable lookups can be eliminated by the vm for virtual calls, meaning you can program using OO techniques and still get good performance.
I know, I know, the JVM is more secure. That's great, except that bounds checking does have significant overhead, and in real-world Java apps it can become a significant problem.
In Sun's HotSpot for example, bounds checking can be (and is) eliminated by the JIT compiler. So, yeah if this was 1997 your argument would be valid, but in today's reality, it's not a major issue.
Face it, Java is slow, and the situation hasn't really improved since the mid-1990s when Java was first released. The only reason we don't notice as often today that it's goddamn slow is because hardware has become tens of thousands of times faster in that same time period. Yes, the hardware designers saved your ass.
You couldn't be more wrong, I don't know how any informed person could even attempt to argue such a laughable position. Java (and other technologies like.NET) have improved by leaps and bounds over the past decade. Hardware helps make things faster, that's a given. But the technologies themselves have been optimized and improved greatly over the past few years.
Java and the JVM's advantages aren't really over C but over statically compiled OO languages like C++.
When you write an app in C++ and use a lot of OO techniques, it causes your application to perform all kinds of lookups and lots of indirection at runtime while resolving virtual calls, etc. Because it's compiled statically, you're always going to pay a huge cost if your application is complex and there's no way to fix it because the application's memory image is... static.
However with Java and other similar technologies like.NET, which can alter and optimize the application at runtime, these types of OO-based indirections can be nearly eliminated if they're part of a bottleneck. The virtual machine can literally devirtualize virtual functions on the fly.
Since C is a much simpler language (good for systems development), these indirections don't exist and a well written C app will probably always be faster than it's Java (or C++) equivalent. It will just be harder to maintain as it grows more complex.
I'm sure most of the patents are in the virutal machine technology like HotSpot and various APIs that are used on the Java platform (like how he mentions Kodak suing over RMI in the article).
Java has checked and unchecked exceptions (Exception vs RuntimeException), so the developer gets to choose how strict to be with parts of their API. Type Erasure can be annoying but it's fairly clever for maintaining backwards compatibility and the end results are much faster than "true generics" found in other platforms.
They don't really "support mono," they package it along with a few associated applications.
This could easily change from release to release. Everyone I know avoids those apps anyway. Not for legal or religious reasons, but simply because they suck.
The funniest thing is that the.NET and Mono platforms aren't even close to being fully compatible.
So the OP is correct, Mono and Wine are good analogs to one another. They're both flaky and mostly incompatible with the real implementation, win32 and.NET.
In a span of mere hours, "some guy" on slashdot successfully deduced the number of lines of code in a Mercedes Benz's computer system network and is already making short work of Toyota!
Come now, do you work for the pentagon or the NSA or some other place that employs mentats such as yourself?
Java's generational garbage collector doesn't leak memory unless you trap references like you mention in your first paragraph. Even then, it's not leaking memory in a traditional sense, you've just prevented the GC from being able to access and free the memory without crashing the application.
Slashdot Mirror
99% of developers are morons, game developers doubly so.
I think this would be a cool tool for evaluating how an application is executed, as well as visualizing call sites and application traversal.
But I think it would be a major pain in the ass for most development purposes.
Coder Protip: Keep the libraries you use in a safe place, so they don't "disappear" in the future.
Resonance Cascade.
Coder Protip: If you're using an API you don't like, use a different one.
And with Java you're lucky, because the development community is so massive, there's at least a couple of implementations.
Right, they totally failed.
That's why Java went into a tail spin and became the most widely used language in the world: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Damn management failures, making the product so successful!
You JVM advocates always throw out that "faster than C" line. I know, I know, you can prove it, too, using one of your many highly-controlled microbenchmarks that have absolutely no relevance in the real world.
I don't think anyone truly knowledgeable about the subject is going to argue that. Java wasn't designed to be a better C, it was designed to be a better C++. And in many ways it truly is, see my post above.
I know, I know, bytecode and JIT compilation allows for CPU-specific optimizations to be done. That's great, except that even the best JVMs today don't do that.
Actually, today *any* semi decent virtual machine will be peforming these optimizations. That's why you see all the benchmarks showing Sun's HotSpot jvm performing so competitively with statically compiled code, even outperforming it in various situations. The cool thing about virtual machines isn't that they can "allow for CPU-specific optimizations," but that they can perform all types application specific optimization at runtime. For example, a virtual machine can analyze the current flow graph and use a technique called escape analysis to allocate data on the stack, even for data where it wouldn't be practical or possible in a statically compiled application. As I mentioned in the above post, vtable lookups can be eliminated by the vm for virtual calls, meaning you can program using OO techniques and still get good performance.
I know, I know, the JVM is more secure. That's great, except that bounds checking does have significant overhead, and in real-world Java apps it can become a significant problem.
In Sun's HotSpot for example, bounds checking can be (and is) eliminated by the JIT compiler. So, yeah if this was 1997 your argument would be valid, but in today's reality, it's not a major issue.
Face it, Java is slow, and the situation hasn't really improved since the mid-1990s when Java was first released. The only reason we don't notice as often today that it's goddamn slow is because hardware has become tens of thousands of times faster in that same time period. Yes, the hardware designers saved your ass.
You couldn't be more wrong, I don't know how any informed person could even attempt to argue such a laughable position. Java (and other technologies like .NET) have improved by leaps and bounds over the past decade. Hardware helps make things faster, that's a given. But the technologies themselves have been optimized and improved greatly over the past few years.
Java and the JVM's advantages aren't really over C but over statically compiled OO languages like C++.
When you write an app in C++ and use a lot of OO techniques, it causes your application to perform all kinds of lookups and lots of indirection at runtime while resolving virtual calls, etc. Because it's compiled statically, you're always going to pay a huge cost if your application is complex and there's no way to fix it because the application's memory image is... static.
However with Java and other similar technologies like .NET, which can alter and optimize the application at runtime, these types of OO-based indirections can be nearly eliminated if they're part of a bottleneck. The virtual machine can literally devirtualize virtual functions on the fly.
Since C is a much simpler language (good for systems development), these indirections don't exist and a well written C app will probably always be faster than it's Java (or C++) equivalent. It will just be harder to maintain as it grows more complex.
I'm sure most of the patents are in the virutal machine technology like HotSpot and various APIs that are used on the Java platform (like how he mentions Kodak suing over RMI in the article).
Java has checked and unchecked exceptions (Exception vs RuntimeException), so the developer gets to choose how strict to be with parts of their API. Type Erasure can be annoying but it's fairly clever for maintaining backwards compatibility and the end results are much faster than "true generics" found in other platforms.
You have to have all of these people on board for things to work.
If no one even attempts a standard and everyone does their own thing in parallel, do you think it would make web developer *easier*?
No fucking way, it would mean you'd get to write the website 10x instead of 3x like you do now.
He's a clone of Bill Gates! Created by Microsoft over the span of the last decade to ensure Microsoft conquers the world!
Look and see: http://investincotedazur.com/en/newsletter/index.php?txt=act9129
*tinfoil hat activated*
They don't really "support mono," they package it along with a few associated applications.
This could easily change from release to release. Everyone I know avoids those apps anyway. Not for legal or religious reasons, but simply because they suck.
....sounds like something a web app developer would say.
I kid, kid. ;)
duh, it's got what gamers crave!
That would be Pablo Picasso.
That's because programming isn't usually an endurance challenge.
"Making something that works" is more important than "talking about how hard you made your job for yourself"
Where in your deluded fantasy land?
I've tried Mono, it sucks compared to both Java and .NET.
It's not even in the same league.
The funniest thing is that the .NET and Mono platforms aren't even close to being fully compatible.
So the OP is correct, Mono and Wine are good analogs to one another. They're both flaky and mostly incompatible with the real implementation, win32 and .NET.
Wow, that's amazing.
In a span of mere hours, "some guy" on slashdot successfully deduced the number of lines of code in a Mercedes Benz's computer system network and is already making short work of Toyota!
Come now, do you work for the pentagon or the NSA or some other place that employs mentats such as yourself?
Toyota's systems have over a 100 million lines of code: http://news.discovery.com/tech/toyota-recall-software-code.html
Not exactly a trivial app to just run strings on.
Ah, my bad. ;)
Ubisoft can always blame "those damn pirates" and claim the DRM development as a failed project tax write off.
And the pirates can still play the game for free with no issues.
And paying customers still get to take it in the ass, now AND when Ubisoft decides to can the online service.
Win, Win, Weeeeee
You must be a terrible programmer (like the parent).
You can't cause a memory leak in Java by not doing something, you have to actively do something stupid to trap memory so it can't be collected.
Serious difference.
This is true, although Google wrote an eclipse builder that can take a class file and convert it to dex format.
So you can use class files directly, Eclipse and the Android SDK will take care of converting them for you (transparently).
Java's generational garbage collector doesn't leak memory unless you trap references like you mention in your first paragraph. Even then, it's not leaking memory in a traditional sense, you've just prevented the GC from being able to access and free the memory without crashing the application.