JavaOne 2008, dag 2, 7:e maj 2008

Vi startar dagen med att konstatera att jetlagen slagit till med full kraft under natten och att vi båda vaknat rätt många timmar innan klockan ringde. Tyvärr kunde vi också konstatera vartefter dagen gick att vi inte lyckats så bra med att välja bra pass att gå på. De flesta vi var på under dagen befann sig någonstans på skalan mellan ”dåligt” och ”irrelevant”, men det fanns ett par guldkorn som tur var.

Lite av den sömnskuld vi byggt upp tjänade vi kanske in på det första allmänna passet där Oracle presenterade ett antal produkter de fått med i köpet av BEA. Inga visioner, inga drömmar. Gäsp.

Det andra passet hölls gemensamt av Ericsson och Sun. De presenterade projektet Sailfin som är en SIP-server som tillägg till applikationsservern Glassfish. Vi var något besvikna på föreläsningen eftersom den mest handlade om hur de byggt servern internt, och vi hade snarare väntat oss mer om användningsscenarier eller kanske jämförelser mellan Sailfin och andra SIP-servrar på marknaden. Det är inte omöjligt att det kommer labbas lite med Sailfin efter att det att vi har kommit hem, men innan dess är det för tidigt att uttala sig om produkten.

Det sista passet innan lunch var mycket välbesökt. Det hölls av Gavin King och handlade om Webbeans. Han utlovade guld och gröna skogar i form av många arkitekturella och designmässiga trevliga egenskaper för den applikation som använde Webbeans. Tyvärr kände vi att föreläsningen inte riktigt förmedlade exakt hur de bra egenskaperna skulle uppnås. Eftersom ingen av oss har använt Webbeans tidigare så är det svårt att göra något klokt uttalande om produkten. Det ser ut att ligga några i sig vettiga tankar bakom ramverket, men vi vill nog se hur det fungerar i praktiken innan vi säger flipp eller flopp.

Efter lunch (som i år faktiskt är hyfsat bra) gick vi på föredraget Mapping Mars av tre killar som jobbade på Arizona State Universitys avdelning för rymdutforskning. De har byggt en applikation, JMars, som de använder för att visa kartdata för Mars. Den finansieras av Nasa och är tänkt att användas för att göra vetenskaplig data från deras olika marsprojekt mer tillgängliga för allmänheten. Vi fick oss många snygga bilder från Mars till livs, men vi kanske inte lärde oss så mycket mer om Java.

Nästa pass var dagens riktiga höjdpunkt. Det hölls av två killar från Intel och hette ”Transactional Memory in Java Technology-Based Systems”. Transaktionsbaserat minne, i deras tappning, betyder att man kan få transaktionslika egenskaper för skrivning och läsning av vanliga variabler.

De beskrev två olika typer av minnestransaktionstekniker som med fördel kan kombineras; mjukvarubaserade transaktioner (STM) samt hårdvarubaserade transaktioner (HTM). För STM utökar de språket Java med ett antal nya nyckelord där det viktigaste heter ”atomic”. Genom att markera block av kod som ”atomic”, så kan man få det som sker inom blocket när det exekveras av en tråd att förefalla atomiskt för alla andra trådar i applikationen. Om atomic-blocket innebär skrivning eller läsning av flera variabler så behöver man inte bry sig om att synkronisera dem med risk för deadlocks som följd, utan Java ser till att de ingående variablerna skyddas på ett bra sätt bakom kulisserna. I det scenariot kan alltså ”atomic” vara ett betydligt bättre verktyg än ”synchronized”.

Hårdvarubaserade transaktioner kräver, förstås, hårdvarustöd och kan användas för att implementera STM på ett effektivt sätt genom att utnyttja funktioner hos processorn. Det kan också användas för att snabba upp den synkronisering som görs i befintliga applikationer genom att HTM-stödet ser till att trådar bara blockeras vid synkroniserade block om de faktiskt gör saker som påverkar andra trådar inne i samma block.

Eftersom STM-stödet kräver ändringar i språket Java så får vi nog lugna oss åtminstone fyra, fem år innan vi kan använda det. Innan dess kanske det hinner dyka upp processorer med HTM-stöd som snabbar upp våra flertrådade applikationer något.

Sist på dagen höll AMD ett allmänt pass som hette ”The Role of the Microprocessor in the Evolution of Java Technology”. Liksom Intel så understryker AMD hur stor skillnad multicore-revolutionen gör för oss som programmerare.

De allmänna passen kan vara värda att besöka för att kunna snappa upp intressanta tillkännagivanden, men tyvärr så levererade AMD inte riktigt på den punkten. Det mest intressanta vi kunde utläsa var att också de också håller på att arbeta med stöd för hårdvarubaserade minnestransaktioner. Det gör att det känns än mer troligt att det är någonting som faktiskt kommer dyka upp i processorerna och i Java i framtiden.

/Fredrik Stålnacke och Kalle Gustafsson, Omegapoint