We're talking technical here and you're throwing in a legal argument?!? What does this have to do with the implementation of the JVM?
"Be different enough to not get sued" is a technical requirement as well as a legal one because it informs the design of your product. For example: the use of a different bytecode format in Dalvik pretty obviously had much more to do with "we can't make it look like a real JVM because we'll get sued" than efficiency; it's not a significantly better format than the standard Java bytecode system and using it trashes your compatibility with common Java libraries and tools.
Obviously, you are an expert on virtual machines and the Android team should listen to your wisdom.
Good ad hominem, bro. How's that working out for you?
I am not an expert, no, but I do know a few things about them and I know a few more about application development, on Android and off. Dalvik is not a good citizen of the Java ecosystem (as evidenced by its inability to do things that are considered very normal, i.e. Groovy or Rhino for scripting). You can't do really basic stuff like LiveConnect because of the twin fails of no bytecode generation (there's no dexer on-device) and, as mentioned, the class limit does a number on Scala and will hose Java 8. These are technical problems that stem from decisions made during the design process, and they're not edge case problems--well, the Scala bit is, but you can surface the same problem by just having a lot of dependencies that pull in a lot of class files.
When you're talking JVMs, you must compare to HotSpot because that's the main game in town. Dalvik doesn't compare well the design decisions inside of Dalvik serve to hobble developers who are not looking to write very simple, Android-idiomatic (which is not Java-idiomatic) CRUD apps. And that sucks. I would like it to be better. It isn't at present. I don't hold out a lot of hopes for improvement, though I would like to be wrong.
Comments
We're talking technical here and you're throwing in a legal argument?!? What does this have to do with the implementation of the JVM?
"Be different enough to not get sued" is a technical requirement as well as a legal one because it informs the design of your product. For example: the use of a different bytecode format in Dalvik pretty obviously had much more to do with "we can't make it look like a real JVM because we'll get sued" than efficiency; it's not a significantly better format than the standard Java bytecode system and using it trashes your compatibility with common Java libraries and tools.
Obviously, you are an expert on virtual machines and the Android team should listen to your wisdom.
Good ad hominem, bro. How's that working out for you?
I am not an expert, no, but I do know a few things about them and I know a few more about application development, on Android and off. Dalvik is not a good citizen of the Java ecosystem (as evidenced by its inability to do things that are considered very normal, i.e. Groovy or Rhino for scripting). You can't do really basic stuff like LiveConnect because of the twin fails of no bytecode generation (there's no dexer on-device) and, as mentioned, the class limit does a number on Scala and will hose Java 8. These are technical problems that stem from decisions made during the design process, and they're not edge case problems--well, the Scala bit is, but you can surface the same problem by just having a lot of dependencies that pull in a lot of class files.
When you're talking JVMs, you must compare to HotSpot because that's the main game in town. Dalvik doesn't compare well the design decisions inside of Dalvik serve to hobble developers who are not looking to write very simple, Android-idiomatic (which is not Java-idiomatic) CRUD apps. And that sucks. I would like it to be better. It isn't at present. I don't hold out a lot of hopes for improvement, though I would like to be wrong.