7 ms·

Seems to me the long standing "Java is slow" versus "that's an old wives tale, Java software can be as fast native" all converges right down to the evidence of

Seems to me the long standing "Java is slow" versus "that's an old wives tale, Java software can be as fast native" all converges right down to the evidence of Android - compared to iOS, it's slow. If Java was just as fast then this would never come up.

axaxs 9y ago
Java can be performant, but still typically has a huge footprint and memory profile. Others will point out that there are multiple implementations of Java, which is true, but to what adoption? IMO, the only thing propping up Java is legacy enterprise and Android. The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. They had a place in the self hosted world, but in the microservice/cloud world, it's a -lot- of overhead. The same is true in smartphones...we have a huge memory use problem in Android. It may be 'performant', but it's still a resource dog.
- flavio81 9y ago
  > The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. Or, you can also say that the adoption of LLVM compilers, Javascript/Node, Python, and Ruby, show that people are more into VMs than ever.
  - axaxs 9y ago
    LLVM is not a vm, despite its name. Node is popular mainly because frontend people want to do backend work. Python is python, it's been around forever and is available. It's also unmatched in scientific realms. Ruby seems falling out of favor.
    - Abekkus 9y ago
      between github, metasploit, and rails, ruby is falling out of favor the way that java has fallen out of favor.
      - axaxs 9y ago
        Well, I don't mean 'dead' by falling out of favor, just trying to gauge the pulse of new projects. Of course Ruby still exists, heck even Fortran has new development jobs, but I wouldn't call it a 'hot' language. Sure that comparison isn't fair or accurate, but an observation. Rails props up Ruby in a similar fashion existing codebases and Android do Java.
    - flavio81 9y ago
      >Ruby seems falling out of favor. Please elaborate, i'm interested.
      - axaxs 9y ago
        Well, I typically look at a few metrics as PL fascinate me a lot. However, I'll be the first to admit I'm not an expert, so take everything below with a grain of salt. First I judge by new projects/tools that interest me. I don't see much ruby there, but a fair amount of python admittedly. This could be biased to what interests me, obviously. The second is people I know. Some are ex ruby devs, none still use it in their line of work. The third is job trends. Ruby, specifically Rails, is just down by any metric. A quick google search sent me to http://www.indeed.com/jobtrends/q-Ruby-on-rails.html http://www.indeed.com/jobtrends/q-Ruby-on-rails.html Again, I said 'seems' because it seems that way to me, not because it is fact.
  - amelius 9y ago
    JavaScript is moving away from VMs in a sense, since WASM has basically unmanaged memory (no garbage collector). That's a good thing, because in theory you could build your own GC on top of it. (I say in theory because the technology is not there yet, in particular on the concurrency front).
    - flavio81 9y ago
      Wasm code is bytecode; it targets a VM.
      - amelius 9y ago
        True, but it's a very simple VM, as it doesn't have a GC.
- amelius 9y ago
  > people just aren't that into VMs anymore Bytecode can be translated quite well to native code. So I'm wondering if this isn't about "VMs versus native" as much as it is about "garbage collected versus unmanaged memory".
  - axaxs 9y ago
    Possibly. The default strategy, at least in the server side world, simply uses too much memory. Compare Go RES memory to an equally implemented Java version. It's typically orders of magnitude smaller.
  - YZF 9y ago
    What's an example of an ahead-of-time compiler that takes bytecode and spits out native code? Can you do inline assembly for the target architecture? I heard a million time how JIT and JVM "could be" just as fast (or some claim faster) than AOT but in practice it hasn't happened. High performance code is written in AOT/native languages.
    - gizmo686 9y ago
      >What's an example of an ahead-of-time compiler that takes bytecode and spits out native code? I believe that is how .NET works (the byte code gets distributed, and the user compiles it to native immidietly before execution). Also, Android's ART is the replacement for Dalvik that compiles Dalvik bytecode into native code at installation.
      - jayd16 9y ago
        Actually, ART is now "JIT guided AOT." The JIT will (re)compile code as needed but the JIT code is stored to disk, thus creating an AOT binary on future runs.
    - graetzer 9y ago
      You can definitely do ahead of time compilation with .net bytecode. That's why you can write iOS apps in c# with xamarin's SDK. I think the performance differences between JIT compiled code and native code mainly come from the 'convenience' features offered by languages such as Java or C#. I am thinking of garbage collection, (default) virtual functions or reflection. In let's say c++ you can do all of these things too, but the cost is not hidden from the developer.
- haberman 9y ago
  A key difference between an ELF binary and a Java .jar is that ELF contains a process image. The loader literally mmaps portions of the executable file into memory, and control is immediately translated to this image (dynamic linking and runtime relocations complicate this a bit, but mainly involve patching the image). Java on the other builds its process image on the heap, using the executable file as input. Nothing is executed out of the binary file directly afaik. I believe classloading (defined in the Java spec) actually prohibits doing too much of this work ahead of time. The JVM has to defer work until startup in case the user wants to define a custom classloader. My knowledge of the JVM is very basic compared to my knowledge of ELF, but I believe the basic gist of this is correct. I'm interested in diggging into this difference more deeply and writing a well-researched blog entry about it.
  - chickenbane 9y ago
    I have good news for you! Android (which never had a JVM) Lollipop replaced its old runtime Dalvik with ART, which is on around 1.5B devices. ART actually compiles Android's bytecode to ELF, though Android calls their variant OAT. OAT, in turn, is a playful anagram of AOT, because what Android now does is even more powerful than the JVM or ELF. Android includes a JIT but it also does nightly profile guided optimizations. So not only does Android perform the preloading optimization you mention for ELF but as the user continues to use their apps Android will continue to optimize the compiled binaries.
    - haberman 9y ago
      Good to know. Does that mean Java classloaders are not supported on Android? And does this approach require breaking compatibility with that aspect of the Java spec?
- hota_mazi 9y ago
  > The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. Did you actually look at the numbers? Go is certainly gaining some popularity, and Rust too (although an order of magnitude below Go) but both of these still have a fraction of the mind share that Java has. You're being dazzled by the hype and forgetting to look at hard data.
bilbo0s 9y ago
I don't know man??? I think you might be overlooking the fundamental flaw in the Android ecosystem... the hardware makers are not incentivised to "care". I understand what the author of the article is saying. Android seems to be flawed, on a business and an architectural level. I'm just not sure changing a programming language will fix that. The resource problems, in fact, arise from the lack of tight integration between hardware and software. Basically, iOS is more than just an OS. It's very tightly integrated with the hardware of the various iPhones. Those integration points are all revisited in every update to ensure no regressions, and often, to implement improvements. Speaking of updates, that's another problem with Android. (If we're being fair, I think that problem too is a problem of the more loose hardware integration). But the fact remains that as long as the OS is yoked with the business requirement of being able to be deployed by any OEM, on any hardware they slap together... Android will have update problems. OEMs are sometimes trying to throw a 2.5 cent network chip onto a 40 cent phone and expect Android to handle it with all the speed and grace that iOS handles the rigorously vetted hardware and professionally customized, hand coded firmware that Apple puts in their phones. This is very difficult to do. In fact, I think it's unreasonable to expect that this can be accomplished at all in the market that Android OEM's have to operate in. Google needs to decide what they want... do they want Android in the hands of the majority of device users? Because if they do... they are going about it absolutely correctly. (Afterall, Microsoft beat Apple SOUNDLY in the pc market... but the reality is that it required many Windows installations to run on some very unstable hardware builds.) Alternatively, Does Google want to make better DEVICES than Apple? If this is what they want to do... yeah... Android is just NOT going to get them there. It probably is a dead end. But either way... it's not because of Java, or Rust, or whatever programming language we're blaming it on today. It really is a problem of ... let's be honest ... a lot of substandard hardware that OEM's are pawning off as being the same as the good stuff. As well as firmware that many of them just don't want to invest much time and money into perfecting. (Because the return on that investment is so low.) You could change your VM and programming language tomorrow... you'd still have the problem of OEM's slapping cheap hardware and barely functional firmware into something that looks just like all the other Android phones and saying, "Buy MINE!!! It's cheaper!!!"
jayd16 9y ago
This post is just ignorant of iOS and Android and the dozens of differences between them that lead to user perf complaints. Everything from Apple's hardware advantage to the way Android handles background apps to the difference in built in library quality(core data vs 'use sqlite or something' for example) all make way more of a difference. These days, the Java code in an android app is compiled to native anyway.
- thanksgiving 9y ago
  > Everything from Apple's hardware advantage to the way Android handles background apps to the difference in built in library quality(core data vs 'use sqlite or something' for example) all make way more of a difference. I'd like to go off a tangent here. On LineageOS, under privacy settings you can deny apps permissions such as run at boot and run in background. I wish deny was default mode in all of Android and that apps would have to ask for permission to run at boot. This is good for the end user and this is good for Google as Play Services should have this turned on by default meaning greater adoption for Google Cloud Messaging. This can't happen in one step because the proverbial cat is currently out of the bag and we have to sort of slowly put it back in. Something similar needs to happen with all permissions. File storage: afaik all apps have access to their own data store. Most apps should not need access to device storage at all. Almost no app should require access to phone permission. For example, look at this page by Capital One: https://www.capitalone.com/applications/mobile/android/permissions/ https://www.capitalone.com/applications/mobile/android/permi... > Don’t worry, we aren’t going to call you to find out your plans for the weekend. This permission allows us to use unique phone information (SIM ID and phone number) to guard against unusual sign-in activity. It’s a little extra security to help protect your money. What is this madness? If it were up to me, I'd ban the capital one app for this amount of ridiculousness. That being said, I am not an iOS fan either. I have problems with iOS as well. Why isn't there a way to limit data usage to say n MB a month? Why in the world should it take an OS update to update iMessage or Safari? How is this still a thing now that the iPhone is almost ten(!) years old?
  - gizmo686 9y ago
    >What is this madness? If it were up to me, I'd ban the capital one app for this amount of ridiculousness. Fingerprinting devices to detect unusual logging activity? This is common. Heck, I've had Google lock me out until I confirmed with my recovery email after logging in from a new device. Much more common is simply getting an email after logging in from a new device. The most common method of doing this is for desktop sites is, I assume, IP address; which obviously does not work for phones.
lern_too_spel 9y ago
There are videos showing the Nexus 5, a midtier phone of its generation, outperforming the iPhone of the subsequent generation in launching apps and getting to first interaction. https://youtu.be/hPhkPXVxISY https://youtu.be/hPhkPXVxISY My own experience is that iOS feels more sluggish than Android for vanilla variants of Android.

axaxs 9y ago

Java can be performant, but still typically has a huge footprint and memory profile. Others will point out that there are multiple implementations of Java, which is true, but to what adoption? IMO, the only thing propping up Java is legacy enterprise and Android. The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. They had a place in the self hosted world, but in the microservice/cloud world, it's a -lot- of overhead. The same is true in smartphones...we have a huge memory use problem in Android. It may be 'performant', but it's still a resource dog.

flavio81 9y ago
> The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. Or, you can also say that the adoption of LLVM compilers, Javascript/Node, Python, and Ruby, show that people are more into VMs than ever.
- axaxs 9y ago
  LLVM is not a vm, despite its name. Node is popular mainly because frontend people want to do backend work. Python is python, it's been around forever and is available. It's also unmatched in scientific realms. Ruby seems falling out of favor.
  - Abekkus 9y ago
    between github, metasploit, and rails, ruby is falling out of favor the way that java has fallen out of favor.
    - axaxs 9y ago
      Well, I don't mean 'dead' by falling out of favor, just trying to gauge the pulse of new projects. Of course Ruby still exists, heck even Fortran has new development jobs, but I wouldn't call it a 'hot' language. Sure that comparison isn't fair or accurate, but an observation. Rails props up Ruby in a similar fashion existing codebases and Android do Java.
  - flavio81 9y ago
    >Ruby seems falling out of favor. Please elaborate, i'm interested.
    - axaxs 9y ago
      Well, I typically look at a few metrics as PL fascinate me a lot. However, I'll be the first to admit I'm not an expert, so take everything below with a grain of salt. First I judge by new projects/tools that interest me. I don't see much ruby there, but a fair amount of python admittedly. This could be biased to what interests me, obviously. The second is people I know. Some are ex ruby devs, none still use it in their line of work. The third is job trends. Ruby, specifically Rails, is just down by any metric. A quick google search sent me to http://www.indeed.com/jobtrends/q-Ruby-on-rails.html http://www.indeed.com/jobtrends/q-Ruby-on-rails.html Again, I said 'seems' because it seems that way to me, not because it is fact.
- amelius 9y ago
  JavaScript is moving away from VMs in a sense, since WASM has basically unmanaged memory (no garbage collector). That's a good thing, because in theory you could build your own GC on top of it. (I say in theory because the technology is not there yet, in particular on the concurrency front).
  - flavio81 9y ago
    Wasm code is bytecode; it targets a VM.
    - amelius 9y ago
      True, but it's a very simple VM, as it doesn't have a GC.
amelius 9y ago
> people just aren't that into VMs anymore Bytecode can be translated quite well to native code. So I'm wondering if this isn't about "VMs versus native" as much as it is about "garbage collected versus unmanaged memory".
- axaxs 9y ago
  Possibly. The default strategy, at least in the server side world, simply uses too much memory. Compare Go RES memory to an equally implemented Java version. It's typically orders of magnitude smaller.
- YZF 9y ago
  What's an example of an ahead-of-time compiler that takes bytecode and spits out native code? Can you do inline assembly for the target architecture? I heard a million time how JIT and JVM "could be" just as fast (or some claim faster) than AOT but in practice it hasn't happened. High performance code is written in AOT/native languages.
  - gizmo686 9y ago
    >What's an example of an ahead-of-time compiler that takes bytecode and spits out native code? I believe that is how .NET works (the byte code gets distributed, and the user compiles it to native immidietly before execution). Also, Android's ART is the replacement for Dalvik that compiles Dalvik bytecode into native code at installation.
    - jayd16 9y ago
      Actually, ART is now "JIT guided AOT." The JIT will (re)compile code as needed but the JIT code is stored to disk, thus creating an AOT binary on future runs.
  - graetzer 9y ago
    You can definitely do ahead of time compilation with .net bytecode. That's why you can write iOS apps in c# with xamarin's SDK. I think the performance differences between JIT compiled code and native code mainly come from the 'convenience' features offered by languages such as Java or C#. I am thinking of garbage collection, (default) virtual functions or reflection. In let's say c++ you can do all of these things too, but the cost is not hidden from the developer.
haberman 9y ago
A key difference between an ELF binary and a Java .jar is that ELF contains a process image. The loader literally mmaps portions of the executable file into memory, and control is immediately translated to this image (dynamic linking and runtime relocations complicate this a bit, but mainly involve patching the image). Java on the other builds its process image on the heap, using the executable file as input. Nothing is executed out of the binary file directly afaik. I believe classloading (defined in the Java spec) actually prohibits doing too much of this work ahead of time. The JVM has to defer work until startup in case the user wants to define a custom classloader. My knowledge of the JVM is very basic compared to my knowledge of ELF, but I believe the basic gist of this is correct. I'm interested in diggging into this difference more deeply and writing a well-researched blog entry about it.
- chickenbane 9y ago
  I have good news for you! Android (which never had a JVM) Lollipop replaced its old runtime Dalvik with ART, which is on around 1.5B devices. ART actually compiles Android's bytecode to ELF, though Android calls their variant OAT. OAT, in turn, is a playful anagram of AOT, because what Android now does is even more powerful than the JVM or ELF. Android includes a JIT but it also does nightly profile guided optimizations. So not only does Android perform the preloading optimization you mention for ELF but as the user continues to use their apps Android will continue to optimize the compiled binaries.
  - haberman 9y ago
    Good to know. Does that mean Java classloaders are not supported on Android? And does this approach require breaking compatibility with that aspect of the Java spec?
hota_mazi 9y ago
> The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. Did you actually look at the numbers? Go is certainly gaining some popularity, and Rust too (although an order of magnitude below Go) but both of these still have a fraction of the mind share that Java has. You're being dazzled by the hype and forgetting to look at hard data.

bilbo0s 9y ago

I don't know man??? I think you might be overlooking the fundamental flaw in the Android ecosystem... the hardware makers are not incentivised to "care". I understand what the author of the article is saying. Android seems to be flawed, on a business and an architectural level. I'm just not sure changing a programming language will fix that. The resource problems, in fact, arise from the lack of tight integration between hardware and software. Basically, iOS is more than just an OS. It's very tightly integrated with the hardware of the various iPhones. Those integration points are all revisited in every update to ensure no regressions, and often, to implement improvements. Speaking of updates, that's another problem with Android. (If we're being fair, I think that problem too is a problem of the more loose hardware integration). But the fact remains that as long as the OS is yoked with the business requirement of being able to be deployed by any OEM, on any hardware they slap together... Android will have update problems. OEMs are sometimes trying to throw a 2.5 cent network chip onto a 40 cent phone and expect Android to handle it with all the speed and grace that iOS handles the rigorously vetted hardware and professionally customized, hand coded firmware that Apple puts in their phones. This is very difficult to do. In fact, I think it's unreasonable to expect that this can be accomplished at all in the market that Android OEM's have to operate in. Google needs to decide what they want... do they want Android in the hands of the majority of device users? Because if they do... they are going about it absolutely correctly. (Afterall, Microsoft beat Apple SOUNDLY in the pc market... but the reality is that it required many Windows installations to run on some very unstable hardware builds.) Alternatively, Does Google want to make better DEVICES than Apple? If this is what they want to do... yeah... Android is just NOT going to get them there. It probably is a dead end. But either way... it's not because of Java, or Rust, or whatever programming language we're blaming it on today. It really is a problem of ... let's be honest ... a lot of substandard hardware that OEM's are pawning off as being the same as the good stuff. As well as firmware that many of them just don't want to invest much time and money into perfecting. (Because the return on that investment is so low.) You could change your VM and programming language tomorrow... you'd still have the problem of OEM's slapping cheap hardware and barely functional firmware into something that looks just like all the other Android phones and saying, "Buy MINE!!! It's cheaper!!!"

jayd16 9y ago

This post is just ignorant of iOS and Android and the dozens of differences between them that lead to user perf complaints. Everything from Apple's hardware advantage to the way Android handles background apps to the difference in built in library quality(core data vs 'use sqlite or something' for example) all make way more of a difference. These days, the Java code in an android app is compiled to native anyway.

thanksgiving 9y ago
> Everything from Apple's hardware advantage to the way Android handles background apps to the difference in built in library quality(core data vs 'use sqlite or something' for example) all make way more of a difference. I'd like to go off a tangent here. On LineageOS, under privacy settings you can deny apps permissions such as run at boot and run in background. I wish deny was default mode in all of Android and that apps would have to ask for permission to run at boot. This is good for the end user and this is good for Google as Play Services should have this turned on by default meaning greater adoption for Google Cloud Messaging. This can't happen in one step because the proverbial cat is currently out of the bag and we have to sort of slowly put it back in. Something similar needs to happen with all permissions. File storage: afaik all apps have access to their own data store. Most apps should not need access to device storage at all. Almost no app should require access to phone permission. For example, look at this page by Capital One: https://www.capitalone.com/applications/mobile/android/permissions/ https://www.capitalone.com/applications/mobile/android/permi... > Don’t worry, we aren’t going to call you to find out your plans for the weekend. This permission allows us to use unique phone information (SIM ID and phone number) to guard against unusual sign-in activity. It’s a little extra security to help protect your money. What is this madness? If it were up to me, I'd ban the capital one app for this amount of ridiculousness. That being said, I am not an iOS fan either. I have problems with iOS as well. Why isn't there a way to limit data usage to say n MB a month? Why in the world should it take an OS update to update iMessage or Safari? How is this still a thing now that the iPhone is almost ten(!) years old?
- gizmo686 9y ago
  >What is this madness? If it were up to me, I'd ban the capital one app for this amount of ridiculousness. Fingerprinting devices to detect unusual logging activity? This is common. Heck, I've had Google lock me out until I confirmed with my recovery email after logging in from a new device. Much more common is simply getting an email after logging in from a new device. The most common method of doing this is for desktop sites is, I assume, IP address; which obviously does not work for phones.

lern_too_spel 9y ago

There are videos showing the Nexus 5, a midtier phone of its generation, outperforming the iPhone of the subsequent generation in launching apps and getting to first interaction. https://youtu.be/hPhkPXVxISY https://youtu.be/hPhkPXVxISY My own experience is that iOS feels more sluggish than Android for vanilla variants of Android.