Swiss Firm Claims Boost In Android App Performance 132
Precision writes to inform us about the Swiss firm Myriad, which claims a 3x boost in Android app performance and longer battery life with a new virtual machine. Myriad says that its technology is 100% compatible with existing Android apps. "The tool is a replacement for the Dalvik virtual machine, which ships as part of the Android platform, and retains full compatibility with existing software. Dalvik Turbo also supports a range of processors including those based on ARM, Intel Atom, and MIPS Architectures."
Another JVM (Score:4, Insightful)
Gimme a break. *Every* JVM company out there claims to have the best performance.
Probably something to do with on the fly optimization of JITted code. Or maybe GC optimization and memory management.
It must be Press Release day here at /.
Re: (Score:2, Interesting)
There was a comment [androidcommunity.com] on one of the Android sites saying that a similar performance improvement was already in the Android tree but was too alpha-y to make it to any production builds.
Java vs Objective C - is iPhone always faster? (Score:2)
Does this imply that on more or less identical hardware (latest ARM + similar battery), the iPhone will always run apps faster and will always have better battery life than an Android phone?
If JIT produces such a noticeable performance boost, does that suggest that the difference between next-gen Android and iPhone will be negligible, or will there always be a significant gap? And if the gap will remain significant, should we care?
Re: (Score:2)
It really depends on the operation and the code being run -- bad code is bad code, after all -- but in general, yes. Native code is generally(eight thousand asterisks here) faster than VM/Sandboxed/JITd/whatever code.
Re: (Score:3, Informative)
You seem to be conflating VMs and runtime environments with JIT compilation. So according to your logic if I JIT compile C code it will somehow run slower than AOT compiled C code? How does that make any sense?
Re: (Score:2)
I've never seen a JIT C compiler, so I can't fairly answer your question. That said, JIT still means there's a step before execution, so likely, yes.
Re: (Score:2)
I've never seen a JIT C compiler, so I can't fairly answer your question.
Then you haven't looked very hard.
That said, JIT still means there's a step before execution, so likely, yes.
Huh? JITing effects start-up time not execution time.
Re: (Score:2)
Huh? JIT means 'Just In Time'. Compilation does not just happen at startup time, but during execution as well. Advanced JITs (like Sun's hotspot compiler) continuously perform a statistical analysis of where compiled code might make a difference.
Re: (Score:1)
Shhh, he's a PHP codah and you're just going to confuse him.
Re: (Score:2)
This sentence makes no sense. A JIT compiler produces compiled native code. So how can native code run faster than.... native code?
That's like saying "assembly code shouldn't be faster than C++ code, since they both end up as machine code". Generally speaking, the closer to the metal a language is, the more performance you can squeeze out of it. That's not to say that assembly is automatically faster than C, which is automatically faster than Java... but ninety-nine times out of a hundred a well-coded asse
Re: (Score:2)
There is one counter-point to that, though: JIT compilers can take advantage of very specific features of your processor (not just things like instruction set extensions; I'm talking about stuff such as the exact size of your cache lines) to optimize exactly for your system. The resulting code probably won't run as well on another computer (might not run at all) but it works great on *your* computer and that's what matters.
Of course, there's no reason that a standard C compiler or whatever can't do similar
Re: (Score:2)
What you say is true, but the key term is "well-coded", there are very few developers that could really produce a hand coded assembly program that runs better than something compiler optimized nowadays.
Further, the issue you have with C compilers and such was covered by the other poster to you- they compile to a generic x86 platform, whilst JIT will compile for the specific processor on the system it is running, this means that there are many circumstances in which Java apps will actually outperform C apps,
Re: (Score:2)
A JIT compiler produces compiled native code. So how can native code run faster than.... native code?
Think of how long it takes to compile an average piece of software. Now think of the time the JIT compiler can afford to spend on compiling the intermediate representation. Sure, the IR makes life much easier, but you still can't afford to go all-out with optimisations that your average stand-alone compiler can (and will) do.
Re: (Score:1)
Re:Java vs Objective C - is iPhone always faster? (Score:4, Informative)
...you can always write the performance sensitive guts of your iPhone app in C or C++ if the Objective-C run time proves to be the bottleneck in your particular case. After all it is GCC that compiles the Obj-C/C/C++ code on that platform...
Re: (Score:2)
Actually, C and ObjC use the LLVM compiler now. I think C++ still uses gcc.
Re: (Score:1)
Re: (Score:2)
LLVM is a compiler back-end; it takes low-level instructions and emits assembly. You still need a front end to turn the source into low-level instructions. GCC can do this, for any language that it has a front-end for (lots), and the result is portable to anything LLVM runs on. GCC is actually pretty widely used for this. Clang is a newer compiler, built specifically to use LLVM for the back-end. It may be what you're thinking of, especially since its C++ front-end is still very much a work-in-progress (C i
Re:Java vs Objective C - is iPhone always faster? (Score:5, Interesting)
Several things come to mind. First, my Nexus One, like the iPhone, burns about 85% of it's power on the display. If it weren't for the display, it could play music and keep the receiver active, and probably do a few more things and have the battery last for days. So, we're really only talking about the last 15%. Second, many applications run in compiled C, like webkit, the network stack, the map application, speech synthesis, 3D rendering, etc. These apps are going to probably be the similar on both phones in terms of efficiency. So, in Java, a lot of what we're really talking about is the code that pops up pretty windows. It's hard for me to imagine that takes much power.
I expect big advances in the future. Low power displays will be huge. After that, maybe we should revisit the JVM.
Re: (Score:2)
Does this imply that on more or less identical hardware (latest ARM + similar battery), the iPhone will always run apps faster and will always have better battery life than an Android phone?
From a performance perspective, no. Android can run native code should a developer decide he wishes to do so.
As for battery life, maybe. As newer devices come out their efficiency is likely to continue to improve but Android devices always have more work to do because they are more capable devices. This extra capability comes from their native ability to multitask. Included in their ability to multitask is the ability to run applications in the background. This has the effect of a perceived reduction in bat
Re: (Score:2)
Gimme a break. *Every* JVM company out there claims to have the best performance. Probably something to do with on the fly optimization of JITted code.
I don't believe the Dalvik _does_ the JIT.
Re: (Score:1)
Re: (Score:1)
It'd be great if you could allocate values on the stack with Java.
Heap only allocation of objects really hurts performance for physicsy stuff and other types of calculations that create a lot of garbage.
Re: (Score:3, Informative)
Keep a list of dead objects, and refill the variables to resurrect whatever's needed. The initial cost of heap allocation can be amortized to nothing that way, for long running program components. As a result, the GC won't be needed, and your performance will be independent of the GC a
Re: (Score:3, Insightful)
That's called resource pooling, and for small objects it's a workaround for a shitty GC. Why bother using a language with garbage collection if working around the GC makes life more difficult than manual memory management? In C or C++ you can treat small objects (points/vectors] as values and let the language copy them transparently, much like Java does with primitive types, and you'd have the best of both worlds. On PCs, a generational GC can be fast enough to not to noticeably impact real-time animation.
Re:Another JVM (Score:4, Informative)
There's nothing wrong with using Java on a resource constrained device. It works fine for most applications, although maybe not for realistic physics simulations.
Even relatively inattentive Java coding (with respect to constructing objects inadvertently) works fine for most things you'd want to do on a most devices you're likely to encounter. It's the usual thing, if you look at your code, only a tiny fraction of it tends to be performance critical.
Now I can't tell you how many hours I've spent dealing with messes created by crappy resource pooling implementations. The irony is that these were all classic examples of premature optimization. Competent programmers make things clear and correct first, then worry about fast. These incompetent implementations were from programmers who worried too much about the performance constraints of the platform and bent over backward trying to shoehorn in every optimization they could think of before ever getting a single jot of performance data. So they ended up with a buggy mess. After ripping all those optimizations out, including the resource pooling, I found that things ran *faster*, although that was less important than the fact the software was *correct*.
Now I agree that if I *were* writing something that had to be very fast (and something like a scientific simulation or cryptanalysis utility that can never be fast enough), and heap based object allocation and garbage collection were going to be a bottleneck, I'd choose something like C++ instead. It's purely a matter of optimizing programmer time either way. I don't want to have to waste my time worrying about optimization.
How to build a flawed API in Java... (Score:5, Informative)
How to build a flawed API in Java...
If a library's performance depends strongly on GC performance, then the programmers should refactor their code to reuse existing objects rather than building new ones all the time.
The absolute worst thing you can do in an object oriented language, which is intended to be used in an object oriented way, is to instance objects without the instancing of them initializing them. The original Java Mail API did this, and it was a steaming pile because of that. I would probably go so far as to suggest that any object oriented language which permitted this was not designed correctly. To reuse the objects, you'd have to be able to reinitialize them, which is basically the same thing.
The typical problem with Java programs and garbage collectors is chasing force-zeroing of pages because they release the memory back to the system, and their security model requires that the memory be zeroed before it is reused by the program. Being a little bit time lazy about doing your GC to reclaim the memory on behalf of the system rather than on behalf of the program you are running almost always results in significant performance improvements in things like Physics engines. In other words, you want a little intentional latency between the time you collect the garbage, and the time you deliver it to the dump.
One of the most obvious recent offenders is Apache Lucene , specifically , which works just great, if you don't do the finalize() and cause the objects to be collected way too early.
So the problem usually boils down to a greedy garbage collector, which is a problem in the JVM, not the library code.
Of course on tiny platforms, the JVM footprint gets pretty large, so you'd also need to gather and LRU the freed heap to avoid it growing out of control from the latency; so you'd need a high water mark as well as a timed delay.
Personally, I really hate garbage collection as a paradigm, especially the garbage collection in Objective C. It claims to be optional, but isn't: as soon as you have one framework that doesn't do an explicit release of an object, your program is forever after addicted to the garbage collector, and slowly accumulates leaks which are "fixed" by the garbage collector, until what you have left is code you can't reuse without also doing garbage collection, infecting any project you bring it into.
-- Terry
Re: (Score:2)
Re: (Score:1)
A functional language might qualify, but is there a true functional language ( one without mutable objects ) which one could label object oriented?
Re: (Score:1, Redundant)
Re: (Score:3, Informative)
The absolute worst thing you can do in an object oriented language,
Perhaps you misunderstand the subject. Caching, memoizing, and/or object pools are all extremely common optimizations. On Android, its the ONLY way you're going to see a video game sustain reasonable FPS. End of discussion.
Its easy to re-initialize an object's state to allow for re-use after it has been instantiated. When the object's life is done, rather than free it, you simply return it to a pool. When a new object of that type is required, you re-initiate an existing instance, remove it from the pool, a
Re: (Score:2)
"Personally, I really hate garbage collection as a paradigm"
That's like "hating virtual memory as a paradigm." It's one particular implementation technique for one particular abstraction (i.e., an abstraction of infinitely large memory, where you don't care about objects you don't need anymore). So, do you "hate virtual memory as a paradigm" as well?
Re: (Score:2)
Personally, I really hate garbage collection as a paradigm
Yeah, We all absolutely love languages which buffer overflow and reference dangling pointers.
Those are orthogonal issues. For example, such issues are even possible in Java. Furthermore, languages like C and C++ have garbage collectors available and such issues can still exist. Even more so, using things like smart pointers in C++ can completely alleviate the issue.
Re: (Score:2)
to be fair, all primitive types like int, float, etc are stored on the stack and not the heap, only objects are
Re: (Score:1)
to be fair, all primitive types like int, float, etc are stored on the stack and not the heap, only objects are
Mostly wrong. That is true only if they are stack variables rather than class or instance variables, and only if they are not arrays (which are also primitives). Everything else is a reference to a heap object.
Re: (Score:3, Insightful)
Not really. This is actually one of the places that java has dramatically improved over the last decade. Most optimized VMs have a heap that uses stack like mechanisms that have reduced the real cost of instantiating an object to about 60 machine instructions vs c++ using 100 to 300. Also, because of how objects are arranged, recently created objects can be reclaimed at virtually no cost. I would link to a couple articles, but the bookmarts are at home and I am on my work machine.
Re: (Score:1)
Actually wrong, reclaiming memory is done automatically when the stack frame goes away. So if a given variable only exists within the stack frame, it's going to be smarter to allocate on the stack than the heap.
Re:Another JVM (Score:4, Insightful)
Not actually. Go back and read what I was saying. The JVM can create an object in its heap far faster than c++ can malloc. In the cases you are talking about, garbage collection in java is also practically free. Also, just because you can not put something on the stack does not mean that java can not do so for you. I made it home from work and have a reference for you.
http://www.ibm.com/developerworks/java/library/j-jtp09275.html
Re: (Score:1)
Thanks for the link, but you really ought to research what you wrote, it's very, very incorrect.
Tips: Learn the difference between stack and heap, learn what malloc does, learn that garbage collection is never, ever free
Yes, jvms are starting to do escape analysis but OpenJDK ~6 and Dalvik don't.
Re: (Score:2)
No its not incorrect, you are just reading into it things that just are not there. I know the difference between stack and heap. I am not saying that heap faster than the stack or that the two are the same. I am saying that underneath the hood java does not exclusively use the heap for objects (for some JVMs) and in the standard case where it does use the heap, it is vastly more efficient than most people assume (faster than c/c++ use of the heap).
That article is 5 years old and JVM's have been using escape
Re: (Score:2)
IME, GC can only be faster if you can afford to 2x the RAM (physical, because virtual more or less doesn't work for GC, unlike malloc/free) and you have problems with fragmentation in malloc/free program (but going to 2x RAM will more or less solve it there too).
Please don't say that GC allocation is fast without accounting for freeing too, otherwise you are just moving the bottleneck where it cannot be easily accounted for.
Re:Another JVM (Score:4, Insightful)
I create objects in C with:
if(freePtr == NULL) {
allocateMoreObjects();
}
object = freePtr;
freePtr = freePtr->nextObject
Now that might be a few instructions, but nowhere near 60. Far more importantly, my objects are allocated out of contigous memory blocks, meaning that cache misses are far more likely to load objects into cache that will be accessed in inner loops. Many geeks still think in terms of machine cycles, rather than L2 cache misses. That's sooo last decade.
Re: (Score:2)
Ummm, what happens when you need to deallocate objects?
The advantage Java has over C/C++ is that it can do pretty much what you describe while maintaining the ability to reclaim memory when objects are no longer needed. An old style heap requires extra accounting overhead to allow for deallocations - something your example doesn't include.
Re: (Score:2)
This was introduced with Java 1.6 update 10. If the compiler notices that the object isn't passed outside of a function (called escape analysis), it'll be allocated on its stack.
Slashvertisements ahoy! (Score:3, Funny)
Towards thee I roll, thou all-destroying but unconquering Virtual Machine.
Re: (Score:2)
It definitely looks like an advertisement. I was hoping to see some kind of technical comparison where you can see a video demonstrating the differences... nope.. just junk
Behold (Score:5, Insightful)
How very very fortunate for everyone involved (unless the problem was the original Dalvik developer's sleep statements). The article is scant on details and the official press release is also very thin [myriadgroup.com]. My big question is whether or not we'll see this quickly adopted and rolled out by manufacturers who've already released Android. For me, assuming this is bug free, I'd like to see how my Motorolla Droid performs on Dalvik Turbo. Will it be as simple as swap image and reboot to switch between the two? Is anything lost in this transition?
At first glance I was certain that they had compiled and optimized the virtual machine to be specific to an architecture
Benoit Schillings is the Chuck Norris of code. (Score:5, Informative)
Re:Benoit Schillings is the Chuck Norris of code. (Score:5, Informative)
You're thinking of Dominic Giampolo. Benoit wrote the App Kit and tons of good bits in the rest of BeOS but he didn't have much to do with the filesystem.
Re: (Score:1)
Re: (Score:2)
>Now, who wants to try a bite?
Even if you're right, what's depressing is that BeOS was the most responsive system I've ever used on a PC..
Which means that even if BeOS is bad, the other are *worst*..
Re:Behold (Score:4, Funny)
Myriad's press release just sounds like Chuck Norris decided to dabble in software development
No, he gave Dalvik a roundhouse kick to the garbage collector.
Re: (Score:1, Interesting)
The question is... is Google going to accept the new VM? Or is this going to be a fork of the original code?
Re: (Score:2)
they just looked at Android and it became three times faster.
Is that the power of open source? ;)
Seriously. "Believe it when I see it" seems to be more the power of open source. If it works, awesome. If not, it's just hype.. open source or closed source..
Re: (Score:1)
Re: (Score:3, Interesting)
There are plenty of reasons a 3X speed improvement could be had. For example, optimizing memory layout for cache performace could do it. If one system had a heap that randomly scatters objects through memory, and the other packs like-fields of objects together in dense arrays, inner loop cache performace can be improved greatly. I saw a factor of 17X in one case. It's amazing to me how few programmers today bother getting down to this all-important performance bottleneck.
Well... (Score:4, Informative)
So, it's not like it's some startup with no experience in that market, trying to make a name for itself. In fact, they would seem to have more to lose than gain by making overzealous claims.
Re:plucky little startup from Switzerland (Score:1, Informative)
Plucky little start-up indeed.. They were called Esmertec in a previous life, and have been around a long time (in mobile phone years). I believe they provide(d) the java implementation for a large share of Sony Ericsson handsets They merged with another company, purple labs, which also came out of a whole host of mobile phone software companies, including the Openwave client software division..
Blah. (Score:2)
JIT is indeed faster. I am not shocked that a Googleplex full of PhDs is already moving in this direction. Google details are at http://groups.google.com/group/android-platform/browse_thread/thread/331d5f5636f5f532?pli=1 [google.com]
Re: (Score:2)
Is there any reason to think the two approaches are mutually exclusive? If like many people think, this involves improvements to the garbage collector, then some of those improvements may well still apply to the JIT, which from the sound of it may have hardly touched the garbage collector at all.
Turbo! (Score:5, Funny)
Back in my day, manufacturers used to slap a turbo button on the front of the case.
And we liked it that way.
Now get off my lawn!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Back in my day, manufacturers used to slap a turbo button on the front of the case.
And we liked it that way.
There's an app for that.
Now get off my lawn!
And for that.
Re: (Score:2)
Re: (Score:2)
I find it quite ironic that a 16mhz 80286 processor was "too fast" for some programs, and required a cpu scaling program to slow the effective cpu speed to run correctly... It puts things into perspective to think that 16mhz was "too fast" at one point in time...
Re: (Score:2)
It was only too fast because of poor programming practices. They assumed a certain MHz processor and so faster CPUs threw off their timing.
Re: (Score:2)
I used to play Sopwith - and yes, it worked. That plane is impossible to control if you're running above about 12MHz :)
Re: (Score:1)
Re: (Score:2)
oooh, I remember my mate's 486DX2, with turbo 66MHz, without 33, all neatly displayed on a little LED panel on the front, ah, those where the days.....
Where're my slippers...?
Re: (Score:2)
I still have my 486 case, with the turbo button. The backside of the button has a dense set of jumpers that with a little (a lot) of dicking around you could make it say 00-99 for each speed (button on/off).
Kuchichaestli (Score:3, Interesting)
Nur i de Schwiiz!
Hopp Schwiiz!
Re: (Score:2)
Proof? (Score:2)
Writing up a blurb saying you have something is one thing.... show us some proof, numbers,... something other than
a claim that you have something.
I am sure Google went over performance and if it could be made to perform better it would have been done. (I Hope... Google?)
I can say I have a million dollars, does not mean I do.
Re: (Score:2, Informative)
No, anyone following the Dalvik VM and android knows it was barely optimized out of the gate.
Google's team has said they are going to optimize the vm as development progresses.
Any technologically savvy want to enlighten me? (Score:2)
Then
Re: (Score:1)
Re: (Score:1)
It's slower than an iPhone.
Now, I have an android handset and I prefer it overall to the iPhone. But the iPhone is a better performer overall.
Once dalvik becomes more mature and has optimizations in place like these, it will be a much closer race.
Re:Any technologically savvy want to enlighten me? (Score:4, Informative)
Google did not miss anything. They were well aware that Dalvik was largly unoptimized. They have been working on creating a JIT compiler for Dalvik, while this other company has been working on other improvements.
Re: (Score:2)
There was some untapped optimization-fu. Its called JIT. See, google wrote Dalvik, not to be faster than standard java, but to enable a bunch of multi-process memory sharing techniques that aren't possible with standard java. What they didn't do is ever implement a just in time compiler. In fact in ever test done, Dalvik performs as well as Sun Java without JIT enabled, which is vastly slower than with JIT. Their comment at the time was that "maybe we'll implement JIT for Dalvik 2.0". Assuming Dalvik
Re: (Score:2)
Re: (Score:2)
Oh really, I didn't realize that happened. That's actually pretty cool then, it means there's progress. The brush off google gave when asked about JIT made me think it'd never happen.
Re: (Score:1, Troll)
The concept is rather simple actually, everyone tells us that java is as fast as C. This will make it three times faster than C...how cool is that?
Re: (Score:1)
You can't directly compare Java and C because they're different in practically every way.
In this case, n "Dalvik Turbo JIT" is 3 times faster than the purely interpreted dalvik VM shipping with android phones.
The JIT version produces code similar to that generated by a C compiler in some ways (native instructions).
Re: (Score:2)
It's also fairly nascent and I wouldn't be surprised if there is plenty of room for improvement.
Why is this needed? (Score:1, Troll)
Why would this be needed? Everyone tells me java is twice as fast as C? This must make it three times faster than C, impressive.
Re: (Score:1)
That's not due to any fundamental limitation. In fact, they are hard at work on creating a JIT for Dalvik [google.com]. It just hasn't been released yet. Once it is, Android applications should become several times faster.
Re: (Score:2)
Interpreted Java is pretty much always slower than C. Java with a JIT has the potential to be faster than C. That's why they're implementing a JIT.
Just in Time Compiling (Score:3, Interesting)
Java hardware acceleration was discarded (Score:3, Interesting)
Java hardware acceleration was discarded by the Android platform.
Imagine if someone were to translate Dalvik into a bytecode that is compatible with the inbuilt Java acceleration of most mobile-market processors.
The fact that Android uses Dalvik instead of Java throws away an important hardware-based performance boost of native Java acceleration.
Re: (Score:1)
Make It Run Real Java (Score:2)
This project looks like it opens the door for a real JVM that runs real Java apps, real Java bytecode, not the Dalvik bytecode that has to be developed for specifically the Android platform. With a real JVM, some Java bytecode already available for download could just work, and porting a lot of the rest should be a lot easier. Which would open up a much larger existing community of developers to target these devices with apps.
Re: (Score:2)
you can already run "real" java bytecode on android. you can import any JAR into an android app and use it ... with the assumption that the interfaces used by the imported code are implemented in android (android implements a large portion of the JDK).
what you can't do is make use of any "real" java app UI. you will never be able to do that as android doesn't support swing or any other standard java UI paradigm.
Re: (Score:2)
The Dalvik JVM runs regular Java bytecode? And regular .java code compiles to run on the Dalvik JVM. So what's the difference between the Dalvik JVM and any other one, except the specific code that implements it?
Are there any open-source implementations of the Swing or other standard Java GUI class libraries, that could be compiled into a JAR, statically linked, and delivered along with the Java app to run on Android under the Dalvik JVM?
Re: (Score:2)
The Dalvik JVM runs regular Java bytecode?
yes. it's not the "dalvik JVM", it's dalvik VM. the difference is that it's not a java standard VM. android uses the java language but it is not run on a java VM.
And regular .java code compiles to run on the Dalvik JVM.
if you mean to say you can compile using a java standard VM and run on the dalvik VM, then yes ... as long as you are only compiling that subset of the JDK that the dalvik VM understands.
i don't think there is any guarantee of that ... but i assume it's going to stay that way as it allows android developers to piggy pack on the large amount of java
Re: (Score:2)
The VM, whether JVM or Dalvik VM, doesn't know how to execute Swing libraries, or any other libraries. That's the point of libraries: they're just code for some machine (virtual or otherwise) to execute. So if the Swing GUI library is statically linked into the same JAR as the application, the J/VM has all the bytecode to execute.
If the Dalvik VM can run the same bytecode files that a JVM can run, and the same .java files can be compiled into that same bytecode, then how is the Dalvik VM different from a st
Re: (Score:2)
The VM, whether JVM or Dalvik VM, doesn't know how to execute Swing libraries, or any other libraries. That's the point of libraries: they're just code for some machine (virtual or otherwise) to execute. So if the Swing GUI library is statically linked into the same JAR as the application, the J/VM has all the bytecode to execute.
in the library uses an "instruction set" that the VM doesn't understand, it won't run obviously. it dalvik doesn't implement the instructions related to the swing GUI, it can't execute those. swing isn't like an implementation of a list. the VM hasn't to bridge to the native OS to be able to do things like draw widgets into a graphics window.
I can't see anyone else saying that the Dalvik VM can run Java bytecode. Only that it runs .dex binaries [wikipedia.org], which are not Java bytecode. Lots of people are saying [google.com] that it doesn't run Java bytecode.
let me quote from the wikipedia page on the dalvik VM,
"A tool called dx is used to convert Java .class files into the .dex format. Multiple classes are included in a si
Re: (Score:2)
OK. It's becoming clear to me that you don't really know what you're talking about. You're repeating what you read in the Wikipedia article, and inferring wrong guesses about it.
If a Java bytecode file requires conversion at all to run on the Dalvik VM, then the Dalvik VM doesn't run Java bytecode. That is not a trivial difference. If I distribute Java bytecode, it will not run on the Dalvik VM. Nearly no one using an Android device is going to go through that coversion process, certainly not enough for a S
Re: (Score:2)
If a Java bytecode file requires conversion at all to run on the Dalvik VM, then the Dalvik VM doesn't run Java bytecode.
sigh. in my first post, i said android can run third party JARs, not dalvik can run JavaVM bytecode. i should have said "use" not "run", sorry. no you can't just copy the JAR onto the phone and run it obviously. from a developer's perspective, it doesn't matter. you import a JAR into your android app project and it works.
i agreed with what you said in your last post if you care to read it. you made a silly assumption about being able to port swing to android. i am sorry about that, but you said it.
i don't k
Re: (Score:1)
droid does?