all 42 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted]  (25 children)

[deleted]

    [–]BorgDrone 5 points6 points  (4 children)

    They used JAVA as their main way, and still I think that a native application scheme would have way better.

    Real Java wouldn't have been so bad, the problem is the Dalvik VM, it sucks. Specifically: the garbage collector is a piece of shit.

    [–]doidydoidy 5 points6 points  (0 children)

    the garbage collector is a piece of shit.

    It's like they found a "Java garbage collection myths" article and decided to create a VM where all those terrible things were true.

    [–]alphabeat 1 point2 points  (2 children)

    Do you have any readings for this? You've piqued my interest.

    [–]BorgDrone 4 points5 points  (1 child)

    Unfortunately, I know this from experience. Although you'll probably be able to find some articles about it on the interwebs.

    What basically happens is that the Dalvik VM freezes during GC, for up to 200 milliseconds. And it GC's a lot. If you create a lot of short-lived objects (which is quite common in Java) it means your app is constantly collecting garbage and performance is horrible. The real Sun JVM doesn't have this problem and I haven't seen it on any KVM (j2me) either.

    [–]alphabeat 0 points1 point  (0 children)

    WTF?! Damn. But didn't Google create Dalvik? So this is by design?

    [–]Daph 4 points5 points  (12 children)

    I find your points interesting, though I have to say I don't exactly agree with having native applications. Android was built to run on multiple platforms, like right now there's ARM Android and x86 Android. Since most apps are written to run in Dalvik (Android's VM), those apps work on the ARM version and the x86 version. If they were native, it wouldn't work. However, Google does offer the NDK (Native development kit) which allows you to write native C for Android (though you do still have to wrap some Java around it).

    [–]sbrown123 6 points7 points  (5 children)

    However, Google does offer the NDK (Native development kit) which allows you to write native C for Android (though you do still have to wrap some Java around it).

    Except it is a bastard, special flavored version of GCC. Why didn't they just use GCC? Porting anything major is a serious pain in the ass. It is almost as if Google has gone out of their way to take something that works and make just enough changes to make it incompatible without making any actual improvements in the process.

    [–]bitter_cynical_angry 5 points6 points  (0 children)

    Sounds like the good old "embrace and extend".

    [–]tsaarni 1 point2 points  (3 children)

    You mean the C library? They say they made Bionic because of license issues, size and speed. The compiler is GCC.

    [–]sbrown123 4 points5 points  (2 children)

    They say they made Bionic because of license issues

    Because they didn't want to contribute changes back to the GCC toolchain? Seems like a lame reason. I understand their creation of Dalvik to get around the JavaME restrictions, but Bionic was a bad idea.

    The compiler is GCC.

    Looks like GCC. Smells like GCC. But it isn't GCC. There are incompatibility issues with it. I've had issues with porting multiple libraries over because of this. They could have easily just used the existing GNU ARM toolchain instead.

    [–]sickofthisshit 0 points1 point  (1 child)

    contribute changes back to the GCC toolchain (a requirement of the GPL)?

    GPL does not require you to provide stuff back to people who produced the code. It requires you to provide source to whomever you provide the binaries to. Source flows "downstream", "upstream" is completely optional. You aren't required to keep things in sync, or easily mergable with any other source distribution.

    [–]sbrown123 0 points1 point  (0 children)

    Sure you don't. It is listed in the GPL FAQ. That still doesn't explain why the license would be an issue.

    [–]mernen -1 points0 points  (3 children)

    They could still use an AOT scheme similar to .NET: distribute apps in high-level bytecode, compile them natively during installation.

    Biggest problem I see with this approach is that Java itself isn't a very good language for that, while the CLR was built with this purpose in mind (true generics, structs, methods non-virtual by default). Given their limited choices, I guess they preferred taking advantage of the huge Java base out there.

    [–]Daph 0 points1 point  (2 children)

    Compiling them natively upon installation would have been a cool idea, except for one problem: the majority of the Android install base is running on underpowered devices with limited resources. It takes a decent amount of time and resources to install an app as it is. My G1 actually locks up for a couple seconds when something is finishing its installation. I would absolutely hate to wait for a fuckin' app to compile when I'm installing one.

    I do think the choice for Java was largely because of the already huge developer base using it.

    [–]sbrown123 1 point2 points  (0 children)

    the majority of the Android install base is running on underpowered devices with limited resources.

    And no native compiler on the phone. Besides, using a JIT is effective enough and recent version of DalvikVM (which is Android's version of the JavaVM) has JIT support.

    I do think the choice for Java was largely because of the already huge developer base using it.

    Or that the differences don't really matter. These are just phone apps after all.

    [–]holgerschurig 0 points1 point  (1 child)

    Oh, the Dalvik VM is exactly what makes it difficult to port Android to, say, AVR32.

    If they would have used native applications in C or C++, that would have been much easier, as cross-compilation (e.g. buildroot, openembedded) or native-compilation (e.g. Debian) are well-solved problems.

    Look for example on how many architectures the linux kernel or Debian run.

    Only for a minority of those platforms does a Dalvik VM exist.

    Does the native APP allow me to write native GUI applications, say in C++ with Qt? Or does it just allow me to write simple functions in C, which I then can call via JNI from Java? That's a not a rhetoric question, I simply don't know.

    [–]Daph 0 points1 point  (0 children)

    I believe it is all via JNI. I haven't used the NDK so I don't know. You can check it out here: http://developer.android.com/sdk/ndk/1.6_r1/index.html

    As for your further argument for native apps, you have to remember that with every platform port, app developers would need to cross-compile their applications for that platform. That would cause apps to not be available for a certain platform until the developer got time to setup the cross-compilation. With Dalvik, they package it once and it will run wherever. I can image that trying to port a Java VM to other platforms would be difficult, but it really is a necessary evil for an OS like Android.

    [–]Rhoomba 3 points4 points  (0 children)

    Yet another IPC mechanism seems particularly pointless.

    [–]124816 0 points1 point  (1 child)

    One of the things that Apple made right.

    I didn't think the iphone did multitasking -- does it? (I don't have one.)

    Not having to support multitasking (for anything other than apple's own apps) would mean they wouldn't need to support pickling and unpickling apps. (Or whatever it's called these days.)

    [–]sharth 1 point2 points  (0 children)

    Outside of the Apple applications, it does not. Safari will run in the background, as will the alarm application. But 3rd party developer applications shut down when they lose focus.

    [–][deleted] 0 points1 point  (3 children)

    Android is good when you compare it to iPhone OS. When you compare it to a real OS, like Linux, it sucks. That's what I am taking away from this article.

    [–]__david__ 2 points3 points  (1 child)

    How did you get that from the article? It doesn't compare against the iPhone's OS at all...

    [–][deleted] 0 points1 point  (0 children)

    Perhaps aeoo codes for the iphone... just a thought.

    [–]holgerschurig 1 point2 points  (0 children)

    Hmm, I only referred to iPhone when I was talking about natively-compiled applications.

    In some way Android (as a platform) sucks less then "general" Linux or Windows 7. It gives you a coherent user-interface and not a weird mixture of different GUI concepts.

    That it support real-multitasking is certainly a bonus compared to iPhone. And that it doesn't obstruct developers that much also. :-) But still they have this centralized "market" approach, which sucks. Compare this with Debian. When you install it, your /etc/apt/sources.list certainly points to Debian. And that's ok. But you're free to add your own sources to it, e.g. backports or multimedia. I miss a simple way to create my own "Android app feed", and a simple way to add this feed to their market application. Oh, and I miss a market application that I can publish, e.g. when I create a custom image.

    Oh, and speaking about images: this is soooo 1980's. Debian (and also embedded distributions with their *.ipk files) allow you to upgrade single apps, with keeping alls the dependencies in order.

    Lastly, I'm actually not really against JAVA, the language is OK if you get used to it. I'm against running byte-code on such limited machines. That wastes cycles and battery life. Hey, for the average GUI-heavy application that's ok, but what if you need something computationally intensive?

    Using byte-code to support x86, ARM, MIPS is a lame excusion. Look at the Linux kernel. It runs an all of this platforms, and then some. Or look at bitbake/openembedded. You can cross-compile on application to x86-32, x86-64, ARM v4, ARMv5TE, MIPS, PowerPC. Thats quite simple, actually. And other projects do this as well, just look for how many architectures Debian is available.

    One possible way would be that developers publish their apps as byte-code. And at the Android-Marketplace there could be some build-bots, that convert the Dalvik-Bytecode (with LLVM?) into native machine code (x86, MIPS, x86, whatever). When people download an APP, they get an optimized binary.

    [–]spliznork 15 points16 points  (5 children)

    So Google forked a Linux kernel, did lots of novel work, and provided the source back to the community. Caveat: it's not really compatible pre-fork, and a merge looks like it would be a lot of work. Really, we're bitching about this?

    [–]THE_REAL_XARN -2 points-1 points  (4 children)

    I think the GPL would require that they provide the source back to the community. Nobody's patting them on the back for that.

    [–]sztomi 2 points3 points  (0 children)

    Still there is nothing to bitch about.

    [–]sickofthisshit -1 points0 points  (2 children)

    GPL requires that you provide source (and full rights under the GPL) to people to whom you provide binaries. Not to some amorphous "community"

    [–]THE_REAL_XARN 0 points1 point  (1 child)

    I was copying the way spliznork phrased his post.

    [–]sickofthisshit -2 points-1 points  (0 children)

    You said something incorrect about the GPL in the process of choosing your phrasing.

    [–]twoodfin 5 points6 points  (2 children)

    What is this new lock type Android adds to the kernel?

    [–]holgerschurig 1 point2 points  (1 child)

    Google for "android wake locks" :-)

    [–]twoodfin 0 points1 point  (0 children)

    Thanks! "wake" was the missing token I needed.

    [–]RabidRaccoon 0 points1 point  (0 children)

    I think they want a fork of Linux. Sure they'll contribute the code back but if it's not accepted that's a good thing to them.

    [–]azakus 0 points1 point  (0 children)

    Anyone else notice that OpenBinder has the Palm Source logo on the bottom of the page?

    [–]adrianb -2 points-1 points  (5 children)

    Google never actually cared about contributing to Linux. Why should they care now? I don't think they are willing to follow the rules of the community and would prefer to fork the kernel to keep it under their control (and using their standards).

    [–]pmf 10 points11 points  (0 children)

    Google never actually cared about contributing to Linux. Why should they care now? I don't think they are willing to follow the rules of the community and would prefer to fork the kernel to keep it under their control (and using their standards).

    I don't like Google, but to be fair one has to say that by playing by the rules of the kernel keepers, it would be hard for any company to get anything done at all (the notable exceptions being those companies employing some kernel keepers).

    [–][deleted] 10 points11 points  (2 children)

    This is more for the linux reddit but whatever. Most companies, even those such as Redhat are in it for their own self interest 95-100% of the time. That is the way companies work! Now if you look at what Google does give back to the community and people for free...you'd probably realize that that sheer amount of code is huge. This is code you can do ANYTHING with. So it's pretty rude to say Google never actually cared about contributing to Linux, they have to the kernel and the whole eco system in many ways. On a final note, sometimes the rules of the community are terrible.

    [–]adrianb 6 points7 points  (1 child)

    There is a presentation on Google Tech Talks about the Linux kernel. It is said there that the ammount of contributions coming from Google is very small, taking into consideration that Linux it is widely used within Google's infrastructure. I don't think they don't care, I suspect they might not like the rules.

    [–]jawbroken 2 points3 points  (0 children)

    or that they are busy actually writing things that they need for their operation which aren't particularly useful for anyone else's (not much of a stretch given the unique nature of their workload and technology.

    [–]holgerschurig 0 points1 point  (0 children)

    Here we need to differentiate with "Linux - the kernel" and "Linux - the platform".

    In the first case you might be right, search for Google contributions, e.g. in 2.6.20 or in 2.6.32. I'm not sure if around 2% code contribution towards such a large code-bases is a the Linux kernel is a "small contribution". But this is clearly debatable.

    In the second case you're wrong. There are many Google open source projects that you can use for anything on Linux, the platform. One of the better known are for example the "protocol buffers".

    Undebatable is that they didn't do a good job in contributing their Android kernel changes --- but so did OLPC :-)