sobota 17. listopadu 2007

Případ Android

Android logoGoogle v průběhu tohoto týdne spustil pekelný sled událostí. Prstem na spoušti se stalo oznámení platformy Android pod záštitou The Open Handset Alliance. Android je zajímavý nejen z technického hlediska, ale především kvůli bezprecedentnímu přístupu k Jave, který může znamenat její samotné rozštěpení. Zkusme se tedy podívat na všechny aspekty případu Android.

Aspekt technický

Android je open source stack pro běh aplikací cílených na mobilní zařízení. Skládá se ze třech základních vrstev: operační systém, middleware pro běh aplikací a základní (systémové) aplikace.

  • Základem celé platformy je Linux Kernel verze 2.6 (doufám, že na hardwaru daných mobilních zařízení bude fungovat lépe než na mém notebooku ;-), který slouží jako vrstva pro přístup k hardwaru.
  • Nad kernelem je postavená hradba céčkových knihoven poskytujících základní služby a rozhraní pro vyšší vrstvy. Mezi základní služby patří 2D/3D (včetně podpory akcelerace) knihovna, embedded relační databáze a webový prohlížeč a nebo knihovna pro práci s audio/video formáty. Hned vedle leží takzvaný runtime což je virtual machine a sada základních systémových API.
  • O patro výše sedí aplikační framework, který poskytuje základní API například pro tvorbu uživatelského rozhraní nebo sdílení dat mezi aplikacemi. Zároveň umožňuje fungovat jako service registry, kde se mohou registrovat jednotlivé služby, které jsou nabízeny k další konzumaci.
  • Úplně na vrchu sedí základní aplikace jako emailový klient, mapa, kontakty atd.

Zatím jsme mluvili v abstraktních pojmech jako API, knihovna, virtual machine a teď se na ně podíváme detailněji. Ona zmiňovaná virtual machine se nazývá Dalvik a je speciálně odladěná pro mobilní zařízení s ohledem na co nejmenší paměťovou náročnost. Každá aplikace běží ve svém vlastním procesu ve vlastní instanci VM. Všechny krabičky z obrázku, které jsou vybarvené modře, jsou psané v jazyce, který je přeložen do meziformátu, který je VM interpretován.

Aspekt politický

Poznámka: nejsem právník.

Bystrého čtenáře jistě napadne paralela s programovacím jazykem Java a JVM (Java Virtual Machine). Jenže Android není ani Java, ani JVM, dokonce ani J2ME a ani J2SE. Důvod je jednoduchý a jmenuje se licence Androidu. Ten je totiž kromě kernelu, který je pod GPL v2, vydán pod Apache Software Licence (dále ASL) a to je kámen úrazu.

Všechny klíčové části, které mohly být použity z platofrmy Java, jsou pod GPL v2 licencí a Sun dobře ví co dělá. Oblast mobilních zařízení je jedna z mála, ve kterých mu Java generuje zisk a proto bylo rozumné držet si určité věci pod kontrolou. Google se ovšem zachoval jako chytrá horákyně. Nemají JVM, ale Davlik VM, který zpracovává Dalvik Executable (.dex) formát což je mírně modifikovaný byte code produkovaný standardním java kompilátorem.

Vývojář tedy píše klasicky ve vývojovém prostředí pro Javu. Před tím než spustí aplikaci v Androidu, je potřeba zavolat speciální konvertor, který převede byte code do Davlik formátu. Další zajímavostí je, že core API Androidu obsahuje každému vývojáři dobře známe knihovny ze standardní Javy jako java.lang.Object a další. Při bližším pohledu člověk zjistí, že to nejsou knihovny všechny. Například chybí knihovny pro tvorbu grafického rozhraní - Swing a AWT.

Je na místě ptát se, jak může Android vzít API Javy a prostě z něj vyextrahovat co potřebuje a dát to pod jinou licencí. Může jednoduše, protože na Core API se uplatňuje takzvaná classpath výjimka. Výjimka existuje proto, aby programy využívající toto API nemusely být vydávané pod GPL v2 licencí a zároveň, aby mohly vznikat další open source implementace Javy s jiným typem open source licence.

Roumenova interpretace:

Google ale vubec nepouziva Sunovsky kod (pouziva kod z projektu Harmony a tim padem je jedno pod jakou licenci jsou zdrojove kody Sunovskeho API pro Java SE nebo Java ME). Navic Classpath exception slouzi pouze k tomu, aby aplikace pouzivajici OpenJDK nemusely byt licencovane pod GPL v2, neumoznuje vsak volbu licence implementacim Javy odvozenych od OpenJDK. Naopak implementace Javy odvozene od OpenJDK MUSI byt licencovane pod GPL v2.

Jinymy slovy, Google nema pravo vzit API Sun Javy, vyextrahovat co chce a publikovat pod jinou licenci jak ty pises. Muze vsak urcite pouzit kod projektu Harmony, kdyz zachova licenci, coz udelal. Classpath vyjimka neexistuje kvuli tomu, aby umoznila implementace Javy s jinym typem open source licence. Implementace Javy s jinym typem open source licence existovaly uz davno pred tim nez OpenJDK bylo licencovano pod GPL v2 s classpath vyjimkou (Harmony, GCJ, atd.). Tomu zadna licence nezabrani, existuji ale jine ochranne prvky (copyright pro ochranu zdrojovych kodu - aby nikdo nekopiroval Sunovsky kod, trademark pro ochranu znacky Java a loga Java a pak jeste patenty pro jednotlive principy, kterych ale Sun z principu nezneuziva a jen je sbira kvuli obrane proti firmam, ktere se rady soudi). Jinym implementacim Javy, ktere nevychazeji z OpenJDK, se nemuze rikat "Java" kvuli trademarku a proto Google na tento trademark nema u Androidu opravneni. OpenJDK umoznuje vytvaret derivaty pouze pod licenci GPL v2 a classpath exception s ostatnima implementacema Javy nema co do cineni.

Přesně tohoto faktu využil Google, který nevzal originál zdrojáky Sunu, ale ty z projektu Harmony, který jsou již pod ASL licencí. Zajímavé je zaptrát po důvodech, které vedly Google k tomu, že byl Android licencován pod ASL. Google zřejmě vsadil na to, že ASL licence umožňuje dobře kombinovat open a closed source projekty. Celkem detailně je to rozebráno v článku Why Google chose the Apache Software License over GPLv2 for Android.

Aspekt sociální

Android si vzal z Javy jenom to co se mu hodilo zrovna do krámu (syntaxe, částečně API). To by mohlo ovšem znamenat nebezpečný precedent do budoucna. Klidně se může stát, že se bude opakovat historie v podobě Mictosoft Javy a vznikne něco co se bude tvářit jako Java, ale Java to ve skutečnosti nebude. Bylo by špatné, kdyby mělo dojít k nějakému štěpení Javy. V případě Androidu je to nebezpečné především díky jeho síle, protože je potenciálně mířen na obrovský segment mobilních zařízení. Bude zajímavé sledovat, jak se k celému problému postaví Sun, který nevydal zatím žádné oficiální stanovisko.

Další zajímavé články k tématu

středa 14. listopadu 2007

CZ podcast 18

Pohodlně se usaďte, dejte si sluchátka na uši, otevřete láhev "božolé" a nechte se orestovat podcastem číslo 18.

Distribuované CVS? Proč ne

Píšu CVS, ale myslím ve skutečnosti distribuovaný version control systém (zkráceně DVCS).

CVS, SVN a další systémy jsou centralizované. Je pouze jedna lokální repository, ke které se přistupuje. Pokud chcete udělat změnu, potřebujete patřičná přístupová práva. Pokud chcete dělat paralelní vývoj, např. potřebujete současně spravovat hlavní vývojovou linii a zároveň historickou (fixy), musíte si v těchto systémech udělat (fork) větev (branch). Rozvětvení je jedinou možností jak paralelně pracovat nad jednou repository. Pokud potřebujete spojit práci ve dvou větvích musí dojit k jejich spojení (merge). Každý kdo to kdy dělal, určitě ví jak je to bolestná operace.

Jednou z typických situací, která se špatně řeší s nástroji jako CVS, je případ kdy dva vývojáři pracují nad jednou sadou souborů paralelně, a v určitý okamžik by potřebovali změny od sebe navzájem. Mají dvě možnosti: manuálně si vyměnit změny a aplikovat je a nebo změny promítnout přímo do repository. Obě možnosti jsou bolestivé. V prvním případě je to především nutnost udělat manuální diff nad změnami a následně jeho aplikaci, což je činnost v pravdě nešikovná. V druhém případě může dojít k zanesení neodladěných změn, které mohou dočasně způsobit problémy (centrální repository byla použita pouze pro synchronizaci mezi vývojáři).

Distribuovaný version control systém (DVCS)

Předchozí povídaní mi umožnilo vytvořit oslí můstek k DVCS. Distribuované verzovací systémy se od těch centralizovaných liší v tom, že namísto jedné centrální repository může existovat repositoří více. Způsob práce se liší od centralizovaného přístupu v tom, že vývojář si může lokálně zkopírovat repository a nad ní začít pracovat. Může dělat commit, update a další dobře známe operace. Tyto změny jsou propagovaný do jeho lokální repository. Ve chvíli kdy se rozhodne, že jeho repository resp. stav práce je v patřičném stavu, provede se merge jeho lokální repository a jiné repository.

Na našem předchozím příkladu si popíšeme jak je možné jej řešit s DVCS. Máme hlavní vývojovou repository. Z ní si udělá vývojář číslo jedna lokální kopii, vývojář dva udělá to samé. Ve chvíli kdy se potřebují synchronizovat, využijí DVCS merge mezi svými lokálním repositořemi. Všechny změny mají u sebe lokálně. Po dohodě může jeden z nich pronést změny (klasický commit) do centrální vývojové repository.

Možné modely práce s DVCS popisuje článek Workflows, který je součástí dokumentace DVCS systému Bazaar. Článek doporučuji k nakouknutí, protože vše je pěkně ilustruje na obrázcích. Modely v něm popsané jsou následující:

  • Solo
  • Partner
  • Centralized
  • Centralized with local commits
  • Decentralized with shared mainline
  • Decentralized with human gatekeeper
  • Decentralized with automatic gatekeeper

Mě osobně zaujaly poslední dva a vysvětlím proč. Decentralized with human gatekeeper je velice vhodný pro open source projekty. Představte si situaci, kdy pracujete na open source projektu, ale nemáte práva k pronesení změn. V případě DVCS si správce open source projektu vytáhne změny z vaší lokální repository, provede merge a pokud je vše v pořádku, pronese je do centrální repository. Tento přístup razí například Jason Van Zyl jakožto hlavní vývojář projektu Maven viz email ve vývojářském mailling listu (GIT je konkrétní DVCS).

For anyone who wants to make changes to Maven but doesn't have access I am going to setup a GIT repository to try and enable some distributed development. After using GIT for about a week I'm having a hard time using SVN but obviously we're not going to be switching anytime soon. But for anyone who has patches or wants to try and work with me to get changes in I am going to try this method of publishing Maven as a GIT repository which will allow anyone to clone the repository and work on any changes you like in a controlled way. Once you clone you can commit changes to your own copy of Maven and do whatever you like. Then in order for me to see your changes I can simply pull from your originally cloned repository to a branch on my side and merge. Merging is sooooooo easy with GIT. So easy in fact that it makes you wonder how SVN got it so wrong and makes it so painful compared to GIT.

Obdobný model se používá například pro Linuxové jádro. Filozofii DVCS pěkně popisuje Lins Torvalds v mailu clarification on git, central repositories and commit access lists, kde se snaží vysvětlit přínos DVCS pro vývoj desktopového systému KDE.

Druhý model práce s DVCS, nazvaný Decentralized with automatic gatekeeper, mě zaujal z toho důvodu, že je v něm integrován takzvaný delayed commit. Tedy commit, který projde až při splnění určitých podmínek, například projdou testy, někdo udělá review apod. Tento přístup se hodí v čase před releasem, kdy je potřeba každou změnu důkladně zvážit, aby nebyla zavlečena nějaká chyba.

each developer has their own branch or branches, plus read-only access to the mainline. A software gatekeeper (e.g. PQM) has commit rights to the main branch. When a developer wants their work merged, they request another person to review it. Once passed review, either the original author or the reviewer asks the gatekeeper to merge it, depending on team policies. The gatekeeper does a merge, a compile, and runs the test suite. If the code passes, it is merged into the mainline.

Decentralized with automatic gatekeeper

DVCS má jak výhody, tak nevýhody a asi určitě se nehodí pro všechny typy projektů. Na druhou stranu musím dodat, že i distribuované verzovací systémy se dají používat stejným způsobem jako centralizované a do těch centralizovaných se naopak začínají přidávat vlastnosti těch decentralizovaných (SVN a lokální commit). Pokud vás DVCS přístup zaujal, pak bych doporučoval k přečtení ještě následující dva články z ruky spoluautora SVN.