Hacker News Reader

Comment by inoop | Hacker News Reader

Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?). The whole 'designed to be open' argument is nonsense.

Let's face it, Android was hacked together by a small team on a deadline. It doesn't seem like a lot of thought went into the design and architecture of the system. The code is buggy, there are no tests, and half the tree doesn't even have comments. Bug reports are ignored, and there are about 22k open issues that are not even being triaged. Case in point: http://code.google.com/p/android/issues/detail?id=19078 (not fixed in ICS)

Android is a rush-job, and the team's obvious lack of experience in handling large software projects is biting them in the ass. Rather than making excuses for their botched together software maybe they should just get their shit together.

View on HN

Your mileage may vary on the quality of the team's job.

From where I stand Android is one of those big corporate projects that lets people watch its source code. The ugly parts are on display for all to see, point and rage at, like you just did.

On the other side of the fence, even tickets (open or closed) for iOs aren't publicly available. http://stackoverflow.com/questions/6355397/list-of-known-xco...

The point is that openness is irrelevant in this discussion. I really don't understand why the auhor of the post attempts to wage the open-vs-closed war, except to distract from the real issue: Android's UI is laggy.

> Java is memory safe, and classloaders have been used since forever to sandbox applications (remember applets?).

Well, except that Android allows apps to run arbitrary native code using the NDK.

> Well, except that Android allows apps to run arbitrary native code using the NDK.

I was under the assumption that they can support native code because of the way they designed Android, not the other way around. I highly doubt that supporting native code was the design rationale here. I think they just designed Dalvik to use Linux threads and assume it to run inside its own process. That certainly makes things much simpler for the VM. The fact that you can safely load native code follows naturally.

Still, supporting native code does not have to dictate how you ensure memory protection, or whether each app has to run inside its own process. You can always run a native library (i.e. a video codec) inside a separate process and use memory-safe communication with the process that runs the Java app. You can also go the NACL route.

There's absolutely no reason why supporting native code would result in a choppy UI on Android.

Yes, you can run arbitrary code using the NDK, but you're still sand-boxed into your application's process. Android relies on the Linux security model where each app runs in its own process as its own user. As such, just like with a Linux application, you'd have to find some sort of privilege escalation exploit before you can start mucking around at will.

Wow your comment is misinformed AND insulting, impressive!

To be fair, my claim that there are no tests is a bit overdrawn.

Reply on news.ycombinator.com