Maybe you refer to specific superset functions of C++ or maybe you are mixing C++ with C#. I don’t know. But C# has in my experience produced far faster, and more stable code than any Java app I have ever encountered. So I think there may be more at play than weighted benchmarks.

Regardless that is not even relevant to this line of discussion.

The problem is that Dalvik is NOT a jvm. The creators of dalvik, as well as google have been excited as hell to say as much. Sure it can handle JVM byte code. But it can handle anything that can throw DEX at it. It is in all senses of the word, a VM.

If google wanted a JVM, they would have had their pick of the proverbial litter in optimized JVMs. They could have just opened up a linux SDK like Nokia did and allow people to use the JVM of their choice. They didn’t do that.

They wanted people originally to use Dalvik as it was intended. As a real true to form VM. They didn’t. Developers demanded access to native environment. So they caved and quickly cobbled together a hack to allow some access to the native environment.

The problem is. That NDK sucks. It’s a hack. And it relies on Dalvik still. It also relies on Dalvik SDK hooks still.

So, assuming they have given up on the dream of using dalvik as a VM. I ask this. Why not just expose a gcc toolchain. let people push linux binaries to the device. Suddenly a trillion and one apps, utilities, and segments of code become directly portable to the phone. No longer are people constrained to the busted up eclipse IDE. And everyone can let dalvik be dalvik and stop being a JVM.

That’s really the point.

As for my solid reasoning. I’ve reiterated this point like 6 posts in a row. You refuse to address it. I can’t reiterate it much more. I am running out of ways to say it.

Java has PROVEN to be faster due to this technique in certan situations than C++.

You also talk alot about programming at the bare metal but i havent seen any mobile programmers writing in asm, so thats a complete load of bull.

OpenGL is still a level of abstraction above the hardware and executing it from Java or from C++ should make hardly an difference, 99% of the worlds mobile games on Nokias (some of which ooze quality) run on java and have been for years and some can easily give the iphone a run for its money.

I agree with the previous posts here you need to back up your arguments with more solid reasoning.

That’s the definition of a user process in Unix, not of a VM. A “virtual machine” is typically just a way to run the same bytecoded program on different hardware machines (at least in the Java terminology, not the VMWare/VirtualBox one).

That does not imply sandboxing, as you believe. This is why Java has JNI, and .net has P/Invoke.

You can compromise a SetUID binary just as well from Java/.net/Dalvik, if it is buggy and you invoke it with the right attack payload. There are no SUID threads by the way.

It’s true that you can compromise a buggy kernel from native code (i.e. performing privilege escalation), and that’s probably the only reasonable complaint I see in your very long post.

From what I read, you simply dislike a VM if it doesn’t completely abstract you from the operating system. No such thing exists, unfortunately.

Also, you would prefer direct native access, except that this allows you to attack the kernel.

Dalvik is a VM. It functions as any other VM would. It interprets byte code, then runs that bytecode into the underlying environment. In this case Android’s linux kernel.

So yes, eventually everything ran through Dalvik does run into the linux kernel.

Now let’s think about this like we would say, virtual box, or vmware workstation. Purposely ignoring Hypervisor scenarios.

The very idea of a VM, is that things executing inside of them… stay inside of them. That way the underlying software, in this case ( and many cases ) linux can manage resource allocation properly. It also ensures that user execution remains contained within those VMs. This is good stuff.

Now, if a user can break out of that VM, and run code directly on the underlying platform… linux, as they can with NDK system calls. Whatever is happening there is no longer being constrained to a VM. VM resource allocation and optimization just got considerably harder. Also, the user now can attack other VMs as they see fit. Additionally, they can possibly attack the underlying kernel.

Compromising Dalvik isn’t so bad. Dalvik executes as a reduced rights user. But if a user compromises a SUID thread, binary, or god knows the kernel itself… you have a real problem. Now nasty nasty stuff like Android rootkitting can occur. It becomes very difficult to recover from an exploited state.

So what I am saying is, Dalvik is a VM. It has all the benefits of a VM so long as it is used as a VM. When you start treating it like a jvm, or a byte code interpreter for a specific language, in tandem with a native execution. You lose a lot of the benefits of the VM.

Now, at this point. Why would you continue to maintain a VM, and all of the policy management, resource allocation, optimization, and security associated with it. If all it really functionally is now… is an over glorified jvm.

More to the point, why not just allow developers to directly access the linux SDK hooks, instead of forcing them to access the NDK via Dalvik.

It doesn’t make any sense at all. Unless you consider that, google simply couldn’t convince their users to use Dalvik. So they circumvented it with a nasty hack. And now they have a big mess they are having trouble keeping cleaned up.

That’s my point. I would prefer direct native access, but if they are going to support dalvik and force people to use it. They should do it properly. Doing a little of one, and a little of the other is just messy and obnoxious. But more than that, it makes security, resource allocation, and optimization a pain on their end. To track threads they will need to pass priority info from dalvik back to the kernel and then compare it to standard posix threads. It’s absurd. No one does that. There’s no precedent.

You seem to be complaining that there is no way to get rid of background tasks to execute a game, that’s a “feature” of multi-tasking, not of using a VM.

Maybe I’m missing your point, but I don’t think you express it very clearly.

In fact, I didn’t say anything about the iPhone. I don’t like the iPhone. I had one for a few years. I loved some parts of it. But their app approval process is just immoral. And, iTunes is utter garbage. I am glad I am on the droid. I have no desire to go back to the iPhone at all. But I do think the iPhone SDK was a much saner design than androids. Sure it locked you into Objective C, but at least they didn’t break the crap out of their design just to try to make everyone happy. Android chose to support Java out of the gate as their SDK language. When the mobile phone devs criticized them for this, they released the NDK. But the NDK was a hack. It was poor design. Now they have apps executing in a VM and on bare metal. They are having a hard time managing resource allocation / security / and policy as a result. From here on it’s only going to get worse. If they had just said “well tough noogs we’re only able to support Java for now.” that would have been better for them in the long run. Maybe choosing Java as their supported SDK language was a mistake. Most developers thought it was. But that’s the choice they made. If they want to change that, they are going to have to do it right. What they are doing now just hurts everyone. And that’s not helping them win over developers or customers.

I still love my droid. Best phone I’ve owned by far. But the SDK, I do truly hate.

If I decide It’s worthwhile I will. At this point I have better things to do.

“”"“well what about the NDK? It still executes through Dalvik, but it bypasses most of the optimization.” — no, it does not “execute through Dalvik”. Dalvik executes Dalvik VM bytecode. The NDK generates chip-specific opcode libraries, linked to Dalvik applications through JNI.”"”

Yeah you are missing the point entirely. To hop into NDK you need to jump through Dalvik. You are still subject to it’s schedular at thread starts. There’s no reason for this, and it frustrates developers. It’s such an obvious hack.

“”"“Their approval process is virtually nonexistent, which results in the possibility for an ( reasonable level of ) anonymous developer to add dangerous applications” — and your proof of this is, what, exactly?”"”

Summercon 2010 Talk.

“”"“Which means rooting the crap out of users just became that much easier.” — and your proof of this is, what, exactly?”"”

Summercon 2010 Talk. And subsequent removal of fake apps that could deliver payloads to users. Namely a Twilight app.

“”"“You are either optimizing and securing inside of Dalvik or you are doing it inside linux. One or the other, definitely not both.” — and your proof of this is, what, exactly?”"”

It’s not a statement of boolean value. It’s an opinion. It’s also kind of the whole point of the editorial. Policy / Security / SDK should either use the Dalvik VM, or execute on Bare metal. If you do it on both you are defeating the whole point of the Virtual Machine and generating a giant mess for developers and users alike.

The only reason I can conceive of for google to be doing what they are doing right now is that they are scared to death of removing dalvik because Java can’t execute without it. They refuse to license a JVM. But at the same time they refuse to release SDK tools for using Dalvik with any other language. This cannot continue. They need to either support other languages in Dalvik, or give up on Dalvik.

I don’t think the time is right yet for Dalvik, and I think that as a design decision using Dalvik was a very bad idea.