3 ms·

Wikipedia says: "At this point in time, the OpenJDK implementation offered by Sun was not as mature or complete as the Java Standard Edition. Instead of licens

by geofft 7y ago

Wikipedia says: "At this point in time, the OpenJDK implementation offered by Sun was not as mature or complete as the Java Standard Edition. Instead of licensing Java, Google chose to develop a cleanroom version of the Java Standard Edition libraries, developing the libraries from a completely fresh start without any access to Sun's code." OpenJDK was released in 2007. Android was founded in 2003 and acquired by Google in 2005. It's entirely possible that if the schedules had been shifted a few years, Android would have gone with OpenJDK. Note that OpenJDK is available under the GPL with the "classpath exception," allowing you to link non-GPL software against it (sorta like the LGPL). Android avoids the GPL in userspace, to the extent of writing their own libc (apparently glibc being under LGPL was not enough).

liara_k 7y ago
Ah, THAT makes sense. Not having their own system licensed under the GPL would explain why licensing of OpenJDK doesn't make the question irrelevant, and the timeline explains why they didn't just use OpenJDK directly. Thanks! Also, OpenJDK is now 12 years old... It seems like forever, and it's kind of weird that events that old are still relevant to live legal disputes, but... I guess that's the speed of software vs. the speed of the U.S. legal system... ;)
stefan_ 7y ago
When Android was started, no embedded system of any kind used glibc. It's now 2019 and still none do. It's not GPL avoidance, it's just glibc being (a) huge (pain) for all the wrong reasons.
- andrekandre 7y ago
  what parts of glibc make it trouble for embedded systems? is it the way it uses memory? or just “too large”?
  - kllrnohj 7y ago
    glibc has a reputation for being bloated. Here's a post from 2002 of Linus complaining about it, for example: http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.html http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.ht... Independently of that glibc also has organizational issues. You see this in some major projects flipping back and forth on it, like Debian switching to EGLIBC in 2009 and then back to glibc in 2015. You continue to see this with the very slow (or outright rejection) adoption of new syscalls: https://lwn.net/Articles/655028/ https://lwn.net/Articles/655028/ It's important to remember glibc is not libc for Linux, and distinctly does not behave as such. If your platform is unapologetically Linux to the core, wouldn't you want something else that tracks the kernel API better? And it's not like Android was unique in not using glibc, either. The *BSD's don't, either.
    - geofft 7y ago
      The job of a libc involves a lot more than just tracking the kernel APIs: it's got a malloc implementation, string handling, userspace buffered I/O and formatting, locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to their native tongue anyway), user and group names and not just numeric IDs, DNS resolution, thread handling, math functions, etc. All of that is quite independent of your kernel and hewing closer to Linux doesn't help you with any of it - except maybe the thread stuff, and for that glibc is the standard pthread implementation for Linux so you're probably better off using it anyway since that's what the kernel developers expect. (In other words, libc is the C standard library, not the kernel's client library for its APIs.) Bloat in terms of amount of code is a confusing argument: you map libraries from disk, so you only use memory for the pages of code that have actually been read from disk and you only use one copy regardless of how many programs are running. You could add a function to glibc to print War and Peace to the screen and the only thing it would do is add a few megabytes of disk usage if nobody called it. Even on Android, disk is cheap. EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use. The BSDs don't use glibc because of licensing concerns, not because they dislike glibc's bloat. (Their own libcs implement just as much, because programs use those features.) My claim upthread was that Android avoided glibc for licensing concerns, not for technical unsuitability; giving the BSDs as an example seems to agree with that argument.
- geofft 7y ago
  Sure, but glibc being bloated doesn't explain why they didn't take working, tested code from glibc and cobble together a stripped-down version instead of starting entirely from scratch. You can absolutely fork a version of glibc that pulls out things like dynamic NSS backends, sunrpc, nscd, etc. even if it won't be accepted upstream, and it'll get you a working libc way faster than writing your own cleanroom libc. (With the important bonus of working with existing software that expects glibc and not just a pure POSIX libc, of which there's quite a bit!) Also, Android isn't "embedded" in the sense you're thinking of: the first Android phone had a 528 MHz ARM processor with DSP coprocessor, 256 MB boot disk + storage on microSD, and 192 MB RAM, which was quite a bit more powerful than e.g. the computer I had in 1995 (75 MHz Pentium, 16 MB RAM, 1 GB disk) that ran Red Hat Linux 6 just fine and definitely far more powerful than the machines glibc was originally developed on. So glibc was certainly not too big for Android. And plenty of "embedded systems" along the lines of Android did / do in fact use glibc, from OpenEmbedded to Emdebian to Maemo. Heck, there was even a project called "embedded glibc" (EGLIBC), which is now the official glibc.
- arebours 7y ago
  This is not true. I've worked for two separate companies making soft for STBs and used glibc in both.

by geofft 7y ago

liara_k 7y ago

Ah, THAT makes sense. Not having their own system licensed under the GPL would explain why licensing of OpenJDK doesn't make the question irrelevant, and the timeline explains why they didn't just use OpenJDK directly. Thanks! Also, OpenJDK is now 12 years old... It seems like forever, and it's kind of weird that events that old are still relevant to live legal disputes, but... I guess that's the speed of software vs. the speed of the U.S. legal system... ;)

stefan_ 7y ago

When Android was started, no embedded system of any kind used glibc. It's now 2019 and still none do. It's not GPL avoidance, it's just glibc being (a) huge (pain) for all the wrong reasons.

andrekandre 7y ago
what parts of glibc make it trouble for embedded systems? is it the way it uses memory? or just “too large”?
- kllrnohj 7y ago
  glibc has a reputation for being bloated. Here's a post from 2002 of Linus complaining about it, for example: http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.html http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.ht... Independently of that glibc also has organizational issues. You see this in some major projects flipping back and forth on it, like Debian switching to EGLIBC in 2009 and then back to glibc in 2015. You continue to see this with the very slow (or outright rejection) adoption of new syscalls: https://lwn.net/Articles/655028/ https://lwn.net/Articles/655028/ It's important to remember glibc is not libc for Linux, and distinctly does not behave as such. If your platform is unapologetically Linux to the core, wouldn't you want something else that tracks the kernel API better? And it's not like Android was unique in not using glibc, either. The *BSD's don't, either.
  - geofft 7y ago
    The job of a libc involves a lot more than just tracking the kernel APIs: it's got a malloc implementation, string handling, userspace buffered I/O and formatting, locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to their native tongue anyway), user and group names and not just numeric IDs, DNS resolution, thread handling, math functions, etc. All of that is quite independent of your kernel and hewing closer to Linux doesn't help you with any of it - except maybe the thread stuff, and for that glibc is the standard pthread implementation for Linux so you're probably better off using it anyway since that's what the kernel developers expect. (In other words, libc is the C standard library, not the kernel's client library for its APIs.) Bloat in terms of amount of code is a confusing argument: you map libraries from disk, so you only use memory for the pages of code that have actually been read from disk and you only use one copy regardless of how many programs are running. You could add a function to glibc to print War and Peace to the screen and the only thing it would do is add a few megabytes of disk usage if nobody called it. Even on Android, disk is cheap. EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use. The BSDs don't use glibc because of licensing concerns, not because they dislike glibc's bloat. (Their own libcs implement just as much, because programs use those features.) My claim upthread was that Android avoided glibc for licensing concerns, not for technical unsuitability; giving the BSDs as an example seems to agree with that argument.
geofft 7y ago
Sure, but glibc being bloated doesn't explain why they didn't take working, tested code from glibc and cobble together a stripped-down version instead of starting entirely from scratch. You can absolutely fork a version of glibc that pulls out things like dynamic NSS backends, sunrpc, nscd, etc. even if it won't be accepted upstream, and it'll get you a working libc way faster than writing your own cleanroom libc. (With the important bonus of working with existing software that expects glibc and not just a pure POSIX libc, of which there's quite a bit!) Also, Android isn't "embedded" in the sense you're thinking of: the first Android phone had a 528 MHz ARM processor with DSP coprocessor, 256 MB boot disk + storage on microSD, and 192 MB RAM, which was quite a bit more powerful than e.g. the computer I had in 1995 (75 MHz Pentium, 16 MB RAM, 1 GB disk) that ran Red Hat Linux 6 just fine and definitely far more powerful than the machines glibc was originally developed on. So glibc was certainly not too big for Android. And plenty of "embedded systems" along the lines of Android did / do in fact use glibc, from OpenEmbedded to Emdebian to Maemo. Heck, there was even a project called "embedded glibc" (EGLIBC), which is now the official glibc.
arebours 7y ago
This is not true. I've worked for two separate companies making soft for STBs and used glibc in both.