4 ms·

Sluggishness and battery life are big complaints about current-gen phones; going higher-level is probably not a good idea. I'm still not sure why Google went w

Sluggishness and battery life are big complaints about current-gen phones; going higher-level is probably not a good idea. I'm still not sure why Google went with Java over C++, other than thinking "phones are fast enough."

rev_null 15y ago
I think there are two reasons that they went with Java. One is the fact that they're not controlling the hardware for android. So it makes sense to use a bytecode compiled language to support different architectures. The other reason I think that Java makes sense is that it makes sandboxing much easier than native compiled code. One of the features of android is the ability to restrict what any program has access to.
Drbble 15y ago
Java isn't so much slower than objective-C if at all, and Android has a native API for low level programming.
- xsmasher 15y ago
  JIT compilation is swell, if you don't count time time it takes to kick in. And you're still at the mercy of the garbage collector. If it doesn't matter because you can use C or C++ for critical parts... well you can do that from Objective-C too, and it's trivial. It's far simpler than working through a JNI bridge. I'm still puzzled by the decision, given the horror of J2ME and the failure of Java on the desktop. Why not C++?
  - Roboprog 15y ago
    Pointers and arrays. It's too much work to develop most things in C and its direct descendants. It's of course a shame that Pascal got pushed aside: most of the speed of C, but with array bounds checking and MUCH less need for pointers due to reference parameters and function return space allocated by the calling routine. And perhaps Pascal is even too much work, since we still have to manually deallocate many types of data, since it lacks even reference counting. I agree with you on the garbage collector, though. It really slows down things by thrashing on multilevel caches, despite generational GC. I would really like to perhaps see something that gave you a choice of either reference counting + destructors, or, garbage collection. I can't see how you could make mixing libraries written for one or the other style work with an arbitrary ref-cnt / GC selection, though. I'd probably miss exception handling in any event, as well. Damn trade offs. I want it all, and I don't want to pay for it!
  - regularfry 15y ago
    Given where we are now, why not go-lang?

rev_null 15y ago

I think there are two reasons that they went with Java. One is the fact that they're not controlling the hardware for android. So it makes sense to use a bytecode compiled language to support different architectures. The other reason I think that Java makes sense is that it makes sandboxing much easier than native compiled code. One of the features of android is the ability to restrict what any program has access to.

Drbble 15y ago

Java isn't so much slower than objective-C if at all, and Android has a native API for low level programming.

xsmasher 15y ago
JIT compilation is swell, if you don't count time time it takes to kick in. And you're still at the mercy of the garbage collector. If it doesn't matter because you can use C or C++ for critical parts... well you can do that from Objective-C too, and it's trivial. It's far simpler than working through a JNI bridge. I'm still puzzled by the decision, given the horror of J2ME and the failure of Java on the desktop. Why not C++?
- Roboprog 15y ago
  Pointers and arrays. It's too much work to develop most things in C and its direct descendants. It's of course a shame that Pascal got pushed aside: most of the speed of C, but with array bounds checking and MUCH less need for pointers due to reference parameters and function return space allocated by the calling routine. And perhaps Pascal is even too much work, since we still have to manually deallocate many types of data, since it lacks even reference counting. I agree with you on the garbage collector, though. It really slows down things by thrashing on multilevel caches, despite generational GC. I would really like to perhaps see something that gave you a choice of either reference counting + destructors, or, garbage collection. I can't see how you could make mixing libraries written for one or the other style work with an arbitrary ref-cnt / GC selection, though. I'd probably miss exception handling in any event, as well. Damn trade offs. I want it all, and I don't want to pay for it!
- regularfry 15y ago
  Given where we are now, why not go-lang?