On Wed, Jan 21, 2009 at 11:32 AM, Dianne Hackborn <[email protected]> wrote: > As a general rule, we are strongly opposed to throwing new libraries into > the base platform unless they will be widely used across many applications > (especially ones that ship with the platform itself). Android is a mobile > platform, and we can't just throw things in and bloat up the system because > they would be useful for a few applications. We've already got too much of > that in the platform. :)
Yes, some of the choices are pretty odd, like including junit, or xmlpull APIs. That is why I was asking: many of javax. API extensions are simple and light-weight, and in some cases replace need for non-standard variants. I can certainly understand not wanting to bundle heavy-weight implementations... although that gets bit weird, if you include javax.xml.parser package, but no DOM and/or SAX implementation. > If these are standard Java libraries and you can just bundle them in with > your own app, I think that is the approach we recommend you take. Ok. This should work with javax packages; the main challenge is to ensure that Sun does actually keep separate API jars even after they get included as standard part of core JDK. > As far as what libraries are included, the decision was largely based on > what things the system and bundled applications actually needed. That > should continue to be a significant part of how we decide what is included. Fair enough. -+ Tatu +- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
