3 ms·

I'm sure Java was chosen because it was the dominant smartphone programming language at a time. And not for any actual good reasons. And we (Android developer

I'm sure Java was chosen because it was the dominant smartphone programming language at a time. And not for any actual good reasons. And we (Android developers) still need to suffer through their poor initial choice of platform; things would be so much better if they exposed a C API as a first-class citizen of the OS, rather than making Java the only first-class way to access Android.

joezydeco 12y ago
BREW. Oh dear god.
rifung 12y ago
You have no idea how happy I am to no longer need to program for Android =D Sadly.. still programming in Java (most of the time).. but one step at a time I guess
vetinari 12y ago
The original Danger Hip-Top also used Java. Rubin had already experience with that. They removed the part that sucked hard (MIDP) and replaced with their own implementation (Dalvik). In 2009, I thought the same way as you do - that C API would be better. However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Today, we have ARM, Intel, MIPS implementations, that are all first class citizens. Compare that to the failure of Windows-on-ARM. Yes, the Java language is nothing to write home about - but there is a lot of existing code written in it, so replacing that would be difficult. Designing another language that could use the same standard library, API semantics AND be effective on small devices is not that easy (for example, Scala and Clojure both bring their own large standard libraries, Clojure also runtime overhead, making them both unusable on small devices).
- asveikau 12y ago
  > Compare that to the failure of Windows-on-ARM. I don't think that failure occurred due to anything other than mismanagement. The Win8 cycle produced many things: * An OS for desktop PCs * Under the hood improvements vs. Win7, like faster boot * A tablet UI * A tablet * A port of NT to ARM * A tablet based on the above which could only run code signed by Microsoft * An app store with a new set of APIs that nobody cares about In a weird attempt to distinguish all of these bullet points they muddied the message. What was Windows 8 exactly? They produced oddities like a Windows tablet that won't run Windows programs (not even after a recompile), and a tablet UI that ran on desktops. Imagine a world where they shipped some other combination of these bullet points. Example: A laptop running ARM and recompiled Win32 apps, with a UI that more resembles Windows 7. I'd argue (and argued at the time) that would be more successful than Windows RT.
- on_and_off 12y ago
  > the Java language is nothing to write home about. Sure, but it is also not as bad as its reputation in hackerNews circles. With the right libraries (Dagger 2, Volley, GreenRobot/EventBus, ...) Java for Android can be quite productive (not to mention that IntelliJ also helps a lot). Kotlin could allow us to go even further and remove most of Java biggest weaknesses.
  - SomeCallMeTim 12y ago
    I object to the underlying assumption that it's OK to need to rewrite my app for every platform it runs on. I want write-once-run-everywhere.
    - on_and_off 12y ago
      write-once-run-everywhere does not work for high quality apps. You can share some of the model code with something like J2objc, but I have yet to see a non trivial app fitting in 2 platforms UX principles written by some sort of write once framework.
      - SomeCallMeTim 12y ago
        Look at almost every top game on iOS and Android for examples of write-once-run-everywhere. It's more true that GUI-heavy apps can be harder to get right, cross-platform. But it's a no-brainer for game development.
        on_and_off 12y ago
        I am talking about apps, not games :) . Of course for games you want to use a cross platform approach, for example with unity. They are a very specific case though. For games : -you probably don't want to use the platform's UI framework (unless you game is extremely simple and even in that case it is probably not the best choice for crossplatform). -the platform specific layer is pretty thin. Google Play Games/Apple Game Center. Share achievements, tweet game events and that's it. None of this applies to regular app though.
- SomeCallMeTim 12y ago
  >However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Just about anything would have been better than Java. I'm not a big fan of C#, but CLR would have been better. Even JavaScript would have been better. But an intermediate VM language (like the LLVM intermediate representation) would have been the best option, if CPU architecture targeting were the concern. I do games, primarily. And writing games in Java (which is what Google tells you to do -- though they finally gave in to pressure and added the NDK) just sucks, because you have to ship the JDK when shipping on every other platform -- or you need to write your game twice. So pretty much every major game uses C/C++ despite it being the ugly stepchild of Android. Google set up the dev environment so that you can add as many target architectures as you want, making your APK "fat", or alternately shipping various APKs with different architectures in them and letting the store pick the appropriate version. Which works, but is ugly. C and C++ have been CPU-architecture-independent for a long time, and if they DIDN'T want to force the multi-binary approach, using LLVM to build to an intermediate language and compiling for each platform would have been an even better fix. Intel and MIPS are not first-class citizens, by the way, because the NDK exists, and many developers still only ship ARM binaries. And while other platforms ship with ARM emulators, they're buggy: An app I'm currently working on just fails on MIPS, and there are few enough people with MIPS devices that the client decided to just not support MIPS (our build process uses libraries that aren't build using the Android.mk system, so I can't just add "mips" to the platform list).

joezydeco 12y ago

BREW. Oh dear god.

rifung 12y ago

You have no idea how happy I am to no longer need to program for Android =D Sadly.. still programming in Java (most of the time).. but one step at a time I guess

vetinari 12y ago

The original Danger Hip-Top also used Java. Rubin had already experience with that. They removed the part that sucked hard (MIDP) and replaced with their own implementation (Dalvik). In 2009, I thought the same way as you do - that C API would be better. However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Today, we have ARM, Intel, MIPS implementations, that are all first class citizens. Compare that to the failure of Windows-on-ARM. Yes, the Java language is nothing to write home about - but there is a lot of existing code written in it, so replacing that would be difficult. Designing another language that could use the same standard library, API semantics AND be effective on small devices is not that easy (for example, Scala and Clojure both bring their own large standard libraries, Clojure also runtime overhead, making them both unusable on small devices).

asveikau 12y ago
> Compare that to the failure of Windows-on-ARM. I don't think that failure occurred due to anything other than mismanagement. The Win8 cycle produced many things: * An OS for desktop PCs * Under the hood improvements vs. Win7, like faster boot * A tablet UI * A tablet * A port of NT to ARM * A tablet based on the above which could only run code signed by Microsoft * An app store with a new set of APIs that nobody cares about In a weird attempt to distinguish all of these bullet points they muddied the message. What was Windows 8 exactly? They produced oddities like a Windows tablet that won't run Windows programs (not even after a recompile), and a tablet UI that ran on desktops. Imagine a world where they shipped some other combination of these bullet points. Example: A laptop running ARM and recompiled Win32 apps, with a UI that more resembles Windows 7. I'd argue (and argued at the time) that would be more successful than Windows RT.
on_and_off 12y ago
> the Java language is nothing to write home about. Sure, but it is also not as bad as its reputation in hackerNews circles. With the right libraries (Dagger 2, Volley, GreenRobot/EventBus, ...) Java for Android can be quite productive (not to mention that IntelliJ also helps a lot). Kotlin could allow us to go even further and remove most of Java biggest weaknesses.
- SomeCallMeTim 12y ago
  I object to the underlying assumption that it's OK to need to rewrite my app for every platform it runs on. I want write-once-run-everywhere.
  - on_and_off 12y ago
    write-once-run-everywhere does not work for high quality apps. You can share some of the model code with something like J2objc, but I have yet to see a non trivial app fitting in 2 platforms UX principles written by some sort of write once framework.
    - SomeCallMeTim 12y ago
      Look at almost every top game on iOS and Android for examples of write-once-run-everywhere. It's more true that GUI-heavy apps can be harder to get right, cross-platform. But it's a no-brainer for game development.
      - on_and_off 12y ago
        I am talking about apps, not games :) . Of course for games you want to use a cross platform approach, for example with unity. They are a very specific case though. For games : -you probably don't want to use the platform's UI framework (unless you game is extremely simple and even in that case it is probably not the best choice for crossplatform). -the platform specific layer is pretty thin. Google Play Games/Apple Game Center. Share achievements, tweet game events and that's it. None of this applies to regular app though.
SomeCallMeTim 12y ago
>However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Just about anything would have been better than Java. I'm not a big fan of C#, but CLR would have been better. Even JavaScript would have been better. But an intermediate VM language (like the LLVM intermediate representation) would have been the best option, if CPU architecture targeting were the concern. I do games, primarily. And writing games in Java (which is what Google tells you to do -- though they finally gave in to pressure and added the NDK) just sucks, because you have to ship the JDK when shipping on every other platform -- or you need to write your game twice. So pretty much every major game uses C/C++ despite it being the ugly stepchild of Android. Google set up the dev environment so that you can add as many target architectures as you want, making your APK "fat", or alternately shipping various APKs with different architectures in them and letting the store pick the appropriate version. Which works, but is ugly. C and C++ have been CPU-architecture-independent for a long time, and if they DIDN'T want to force the multi-binary approach, using LLVM to build to an intermediate language and compiling for each platform would have been an even better fix. Intel and MIPS are not first-class citizens, by the way, because the NDK exists, and many developers still only ship ARM binaries. And while other platforms ship with ARM emulators, they're buggy: An app I'm currently working on just fails on MIPS, and there are few enough people with MIPS devices that the client decided to just not support MIPS (our build process uses libraries that aren't build using the Android.mk system, so I can't just add "mips" to the platform list).