jAbLoK

Vezměme si jednoduchý kousek kódu, který po řádcích čte data ze standardního vstupu a bez velkých cirátů je přeposílá na standardní výstup:

import java.io.*;
public class StreamEcho {
   public static void main(String[] args) throws Exception {
      BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
      for (String line = br.readLine(); line != null; line = br.readLine()) {
         System.out.println(line);
      }
   }
}

Teď si vezměme perlový ekvivalent:

#!/usr/bin/perl -w

use strict;

while (<STDIN>) {
   print;
}

A nakonec oběma verzemi prožeňte pár GB textových dat (data napřed něčím přečtěte jen tak, ať se v obou případech využívá disková cache). Taky vám perlová verze běží třikrát rychleji? Co s tím?

Aktualizace: podle komentářů důvodem bude hlavně konverze do Unicode a zpět, kterou se perlový kód narozdíl od Javy neobtěžuje (zmínili Zamboch a Petr Holík). Další rozdíl může být v tom, že System.out.println pokaždé provede flush (zmínil podlesh). Díky všem zúčastněným diskutérům!

Přehledná dokumentace častých výjimek v Javě: http://rymden.nu/exceptions.html

(via Crazyjoe @ Java @ Okoun)

Vývojáři Google App Engine včera zveřejnili stručnou roadmapu, z které vyplývá, že do března 2009 by nás mělo čekat následující:

• explicitní podpora pro práci s “velkými” soubory (tedy nejspíš možnost uložit blob větší než 1MB)
• import/export pro opravdu velké databáze
• účtování provozu nad míru
• podpora pro dosud nejmenovaný jazyk
• uptime monitoring

K tomu postřehy z včerejšího Google Developer’s Day:, kde AppEngine zastupoval Jon McAlister:

• “opravdu nepovíme, jaký jazyk přidáme”
• s Javou je velký problém kvůli footprintu JVM, takže na tu to nevypadá
• vážně se uvažuje o nějaké podpoře asynchronního zpracovávání 

S laskavým svolením svého dlouholetého Kolese si dovolím čtenáře jAbLoKu upozornit na “Enterprise Social Bookmarking” o Javě, Web 2.0, Google, atp. jehož jsem skromným přispěvovatelem a spoluautorem:

http://lincovery.m-atelier.cz/

… se jmenuje článek od Joela Spolskeho, kde autor vysvětluje základní myšlenku Map/Reduce (tedy převést problém na paralelizovatelné zpracovávání seznamů) na JavaScriptu.

Lispu neznaje, první odpověď, která mě na otázku v nadpisu napadla, byla: no jo, perl

Javu samotnou hanět nezačnu ani náhodou, nicméně na Joelově stížnosti na “Java-only” vzdělávání něco bude.

Jak to vypadá, když se za pomocí J2EE vytváří webová aplikace, jejíž databáze obsahuje přes dva petabajty dat (peta = 1024⁵) a jejíž dvě stě milionů registrovaných uživatelů jejím prostřednictvím v kterýkoli čas nabízí okolo sta miliónů položek?

Architektura eBay

• na nejhrubší úrovni rozděleno na databázovou vrstvu, aplikační vstvu, vyhledávací systém a operations
• Aplikační vrstva:
  • nedrží stav (tedy žádné sessions, natož stateful session beans)
    • schválně jsem se podíval na HTTP hlavičky, zaujala mě cookie jménem “nonsession”
  • asi 100 funkčních celků, v terminologii eBay “apps” (někdo by možná řekl “business services”), dohromady to dělá cca 15,000 serverů
  • aplikační servery spolu nekomunikují, běží nezávisle na sobě (což lze snadno díky předchozímu bodu)
• Databázová vrstva:
  • rozdělena vertikálně na něco přes 70 funkčních celků (databází). Ty jsou dále řezány horizontálně podle hlavního klíče pro daný logický celek
  • většina náročných obvykle databázových operací se provádí na aplikační vrstvě; zmiňují se joiny, kontrola referenční integrity, třídění. Nepěstují se žádné uložené procedury (sem tam nějaký jednoduchý trigger)
  • eBay nepoužívá transakce (tedy kromě PayPalu, který pod eBay taky patří)
  • v praxi to znamená, že je vymezena skupina životně důležitých dat, které musí být vždy v konzistentním stavu, u ostatních se garantuje pouze “best effort”

Kdy se hodí Java?

Zajímavé jsou použité technologie: J2EE (konkrétně WebSphere) a Oracle, čímž se eBay výraně odlišuje od různých Flickrů a podobné havěti. Co mají ale tyto weby s eBay společné, jsou architektonické patterny, které se na hony vzdalují představě správné J2EE aplikace z dob EJB2.0. Ale na tom samozřejmě není nic divného.

Proč tedy v eBay Javu vůbec používají?

Dan Pritchett ve své prezentaci z roku 2006 píše: “[we] rewrote the entire application in J2EE … which gave us chance to architect the code for reuse and separation of duties”. A co si tak vzpomínám, to byl možná hlavní důvod, proč jsem se kdysi dávno po nějakých pěti letech s Perlem a PHP pouštěl do psaní webových aplikací v Javě.

Odkazy

• InfoQ Interview: Dan Pritchett on Architecture at eBay
• Dan Pritchett: The eBay Architecture (PDF, prezentace z SD Fora 2006)
• eBay Architecture at HighScalability.com
• Nati Shalom: Why most large-scale Web sites are not written in Java

I pokud vás žádné gridy a podobné moderní výmysly vůbec nezajímají, na GridGain se podívejte aspoň pro příklad, jak taky může vypadat JavaDoc-em generovaná dokumentace API:

.

“Start Here” anotace, prolinkování s Wiki a fóry, jednotná struktura popisků tříd. Vlastně žádná věda. Ale potěší.

Co třeba takovýto (svou jednoduchostí už na úrovni skriptovacích jazyků) kód vypisující řádky textového souboru:

TextFile textfile = new TextFile(new File(f), "UTF-8");
int lineNumber = 0;
for(String line : textfile) {
   System.out.printf("%6d: %s%n", ++lineNumber, line)
} 

Tento příklad a povídání o dalších vybraných novinkách “Tygří” javy najdete v článku Davida Flanagan na OnJava.com nazvaném Five Favorite Features from 5.0

.