Pět a jeden absurdní důvod proč nemáme v JDK podporu JSON

Pokaždé když pracuji v Jave s JSON mám pocit, že jsme stopadesát let za opicemi. Většinou sice používám skvělou knihovnu Jackson (pozor nejedná se o pohrobka ikony pop music Michaela Jacksona), ale i její použití je jako jíti s kanonem na vrabce. Mám úplně jednoduchou strukturu {"l":"0","u":"1","v":1338207547}, kterou bych rád deserializoval do mapy. Opravdu nerozumím tomu proč už v standardním JDK Javy neexistuje stupidní jednoduché API, které mi to umožní. Napadá mě několik vysvětlení.

• Někoho rajcuje představa 100MB WARu k jehož dosáhnutí není potřeba vytvářet složitou aplikaci, ale vývojář si vystačí s pár základními problémy.
• Tvůrci Apache Jakarta Commons nevědí co dělají. Nicméně to nebrání většině aplikací používat právě jejich knihovny.
• JCP proces pro rozšiřování Javy je úplně k ničemu, neboť přidávání nových a potřebných API nefunguje. Mimochodem jak dlouho už čekáme na nové API pro práci s datumy? 
• Nevylučuji ani možnost, že moje požadavky na něco čemu se říká JDK, tedy standardní vývojový kit,  jsou značně přemrštěné a všichni si posledních deset let vystačíme přibližně s jedněmi a těmi samými prostředky.
• Práce na JSON je pro mě z nepochopitelných důvodů vázaná na Java EE. Touto logikou by ovšem v JDK nemohl skončit například HTTP server a nebo JAXB. O nesmyslech typu embedované databáze ani nemluvě.
• JSON je technologie, o které nikdo v Oracle neslyšel. Případně si jí spojuje s konkurencí v podobě JavaScriptu.

Opravdu tomu nerozumím. Přidání nových API a rozšíření JDK je totiž oproti změnám syntaxe jazyka věcí zpětně kompatibilní. Můžeme se zde točit na faktu, že i nafouknuté JDK by bylo problém, ale z toho důvodu přece voláme po jeho modularitě.  Vlastně je to takový deadlock a teď se pomalu čeká na to kde to vyhnije.

Tam kde je možné Javu inovovat za cenu menšího rizika se to neděje. Namísto toho se její autoři pouští to riskantních podniků změny syntaxe.

Pozor na minor updaty Javy

Do Javy 7u6 (update 6) a Javy 8 se chystá změna hashovacího algoritmu pro stringové klíče do všech standardních implementací java.util.Map (HashMap, Hashtable, LinkedHashMap, WeakHashMap, ConcurrentHashMap). Tvůrci si slibují, že díky těmto změnám sníží riziko kolizí a tím pádem nebude docházet ke zpomalení. Více si můžete ostatně přečíst v oznámení této změny. To co je na celé téhle záplatě zajímave je následující poznámka.

The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values.

Přestože to je explicitně zmíněné v kontraktu Mapy, stejně bude existovat, a to bych se klidně vsadil, hromada kódu který třeba i nepřímo závisí na pořadí, v jakém se budou klíče vracet. Z mého pohledu je tohle zpětně nekompatibilní změna, ačkoliv skrytá a efektivní pokud dojde k naplnění určité podmínky (možná o to hůře protože to neodhalí standardní testy), a neměla jít rozhodně do updatu Javy 7. Osobně už jsem několikrát nepěkně sedl na lep vlastní slepé víře v to, že změny v updatech Javy jsou kompatibilní a nehrozí žádné riziko, a dal svolení k provedení updatu, protože nám přece nic nehrozí... Zvedám proto v tomhle případě varovný prst. Pozor na tenhle update, chyby v kódu se mohou projevit za velmi specifických podmínek a tedy velmi zákeřně.

Spring framework tréninkové materiály

Tréninkové materiály k mému školeni Spring framework, jsou k dispozici na GitHubu. Prezentace k jednotlivým částem jsou odlinkované přímo z README.md a najdete je i na mém SlideShare profilu.

CZ Podcast 64 - iOS, iPhone, iPad

S tím zvukem to zase není úplně ono, ale jinak se nám s panem velkostatkářem Filem povedl dost luxusní podcast s týpkama z Inmite o vývoji pro iOS. Poslechněte si to a dejte nám vědět. Příště se bude točit buďto o hrůzostrašných historkách z korporací, abychom zase najeli na méně vážnou notu. Nebo budeme mít, a teď pozor, low level téma a podiváme se na zoubek hackování mobilních a webových aplikací. Slovy klasika: jsme otevřeni všem možnostem přátelé.

MongoDB pro Java vývojáře

Na včerejším setkání JBoss User Group v Brně jsem měl prezentaci na téma MongoDB. Slajdy najdete o kousek níže, rád bych ještě vypíchnul pár myšlenek, které zazněly, ale ze slajdů nemusí být úplně patrné.

• NoSQL není jenom o velkých data. Speciálně MongoDB výrazně redukuje složitost persistentí vrstvy. Rozdíl mezi světem dokumentů a modelu tříd je mnohem menší než je to v případě relačních databází. Pro většinu aplikací, které v uvozovkách vezmou data a pošlou je na výstup, nepřináší relační databáze žádný benefit (kromě toho, že jste s ní pracovali posledních deset let ;-)
• Při použití MongoDB a obecně NoSQL řešíte jiný typy problému, než které jste zvyklí řešit v relačním světě. Na druhou stranu vám odpadají problémy, které souvisí s managementem persistentního kontextu.
• MongoDB není náhrada relačních databází, je to vhodný doplněk nebo alternativa chceteli. Relační databáze dávají perfektní smysl pro určité typy úkolů.
• Smiřte se s tím, že občas povede návrh dokumentů k tomu, že budete mít redundantní data. Jinými slovy rovnou zapomeňte na nějakou normalizaci.

MongoDB for Java Developers

View more presentations from Roman Pichlik