Not even remotely true. In fact, there are JVMs (not necessarily in phones yet) that can pull implicit threads out of not explicitly threaded code. Sun's MAJC project was one of these, there are others. It's hardly an issue for the near future anyway.. you don't need anything like that on a dual-headed ARM -- particularly when you have real multitasking, as on Android, each core will have plenty of work to do when the phone gets busy.
And of course, how the JVM actually handles threads, whether they're real or simulated, is entirely hidden to applications written in Java. Decisions the JVM and OS make on today's phones will be tuned differently for true SMP systems. That's actually true of native systems, too... the kernel is ultimately in charge of how threads are handled, anyway.
Objective-C is essentially a proprietary language, and will live or die entirely on Apple's fortunes. That's not to suggest it's going to fail any time soon, not as long as Apple can keep selling the same stuff for twice the price. But it's useless outside Apple's walled garden.
Directly from Java's Website:
One major difference between developing on Linux from other Unix operating systems is the system threads library. In Java 2 releases prior to 1.3, the Java virtual machine uses its own threads library, known as green threads, to implement threads in the Java platform. The advantage here is that green threads minimize the Java virtual machine's exposure to differences in the Linux threads library and makes the port easier to complete. The downside is that using green threads means system threads on Linux are not taken advantage of and so the Java virtual machine is not scalable when additional CPUs are added.
Currently the only way to get Android to actually thread is to use JNI to run native threads.
Also, I'm not sure if you are a developer or not, but if you had ever written a threaded program and actually benchmarked it you would know that contention for concurrency / locking can bring a threading program to a crawl or defeat the purpose altogether, therefore you should be very wary of solutions that claim to automatically 'thread' a program.
My latter point was about threading, my main point was that Java as a platform now led by Oracle will not be able to contend with a GCC compiled program; The iPhone will continue to enjoy superior performance with native code, there is just no debating that.
Although I understand why Java was used...Java will cause the demise of Android and the dependency on the java platform as a whole long before Android as an operating system will experience pressure from market forces. I'm no fan of apple, but compiled Objective-C has a bright future ahead of it where Java simply does not. When mobile phones start to receive multi-core processors Java will become even more of a hindrance because the Linux kernel attempts to manage user-threads intelligently, Java virtualizes the operating system not allowing TRUE threads to be managed, or allocated to the hardware efficiently.
Slashdot Mirror
Not even remotely true. In fact, there are JVMs (not necessarily in phones yet) that can pull implicit threads out of not explicitly threaded code. Sun's MAJC project was one of these, there are others. It's hardly an issue for the near future anyway.. you don't need anything like that on a dual-headed ARM -- particularly when you have real multitasking, as on Android, each core will have plenty of work to do when the phone gets busy.
And of course, how the JVM actually handles threads, whether they're real or simulated, is entirely hidden to applications written in Java. Decisions the JVM and OS make on today's phones will be tuned differently for true SMP systems. That's actually true of native systems, too... the kernel is ultimately in charge of how threads are handled, anyway.
Objective-C is essentially a proprietary language, and will live or die entirely on Apple's fortunes. That's not to suggest it's going to fail any time soon, not as long as Apple can keep selling the same stuff for twice the price. But it's useless outside Apple's walled garden.
Directly from Java's Website: One major difference between developing on Linux from other Unix operating systems is the system threads library. In Java 2 releases prior to 1.3, the Java virtual machine uses its own threads library, known as green threads, to implement threads in the Java platform. The advantage here is that green threads minimize the Java virtual machine's exposure to differences in the Linux threads library and makes the port easier to complete. The downside is that using green threads means system threads on Linux are not taken advantage of and so the Java virtual machine is not scalable when additional CPUs are added. Currently the only way to get Android to actually thread is to use JNI to run native threads. Also, I'm not sure if you are a developer or not, but if you had ever written a threaded program and actually benchmarked it you would know that contention for concurrency / locking can bring a threading program to a crawl or defeat the purpose altogether, therefore you should be very wary of solutions that claim to automatically 'thread' a program. My latter point was about threading, my main point was that Java as a platform now led by Oracle will not be able to contend with a GCC compiled program; The iPhone will continue to enjoy superior performance with native code, there is just no debating that.
Although I understand why Java was used...Java will cause the demise of Android and the dependency on the java platform as a whole long before Android as an operating system will experience pressure from market forces. I'm no fan of apple, but compiled Objective-C has a bright future ahead of it where Java simply does not. When mobile phones start to receive multi-core processors Java will become even more of a hindrance because the Linux kernel attempts to manage user-threads intelligently, Java virtualizes the operating system not allowing TRUE threads to be managed, or allocated to the hardware efficiently.