Lidt baggrundschecks på manden er dog ikke af vejen, specielt hans tanker om biologi og sundhed må siges at tangere kvaksalveri, men det er jo også en anden verden: Følger man et dårligt råd af en comp.sci. forsker har man måske spildt tid og penge, og står med håneretten; får man et forkert råd af en læge eller en biolog er man i værste fald død.

Ja, der ryger nok en af hans bøger på min læseliste, men også en fra hans “skeptikere”.

Så var der demoerne, og de var hver for sig interessante:

• En kunne visualisere grafdata (gephi.org)
• En kunne få en bil til at styre sig selv – med Java RTS (eller, viste det sig, delvist med Java RTS)
• En kunne samle sundhedsdata fra en håndholdt dims og vise dem på en telefon eller webside
• En kunne scanne biler i realtid
• En der havde en pen, der var en computer.
• Jeg har vist glemt én til?

Fint nok og spændende (pånær måske visualiseringsgutten), men jeg synes det mest tankevækkende var at have den eksponentielle vækst i baghovedet under præsentationerne: Tænk hvad vi kan visualisere, styre, scanne, indsamle, etc. x10 eller x100. Tænk hvis de sensorer, der skal bruges er 10x mindre end i dag – eller 100x. Spændende, og ikke mindst skræmmende!

Plus: Mulighederne er “mind-boggling”.

Minus: Mulighederne er “scary as hell”.

“Double-checked locking” on collection

class Unsafe {
  private Map<String, Object> map = null;
  void useMap() {
    if (map == null) {
      initMap();
    }
    // use map
  }
  void initMap() {
    if (map == null) {
      map = new HashMap<String, Object>();
      // fyld i map
   }

Boom: ConcurrentModificationException!

Første løsning: Så lad dog være med at være lazy!

Ellers: “Cheezy read-write pattern”: Brug lokal variabel i initMap, og brug volatile på mappen.

Many readers – few writers

Hvor der er få, der skriver (og typisk serielt), men mange, der skriver. Løsninger:

• Synchronized Data Structures
• ReadWriteLock
• Copy-on-write
• ConcurrentHashMap.

De har forskellige fordele og ulemper, men hvis du ændrer data sjældent nok, så bruge copy-on-write.

Many writers, few readers

Logging, f.eks… her skriver man jo en masse data, men de læses ikke, de skrives bare videre. Tre mulige

• Synchronized Data Structures: Dårlig idé! Blokerer for ofte.
• ConcurrentHashMap and friends: Som regel den bedste idé.
• Asynchronous (background processing): God idé, specielt hvis opgaven er seriel i natur, f.eks. logning til disk.

Hvis man bruger den sidste og bruger TaskExecutor, så husk at dine køer kan løbe fuld.

Husk nu:

Hvis koden ikke er en performance bottleneck, så LAD VÆRE med at optimere på det.

Brug nu bare ConcurrentXxx-klasserne…

Plus: Manden ved noget om det han taler om.

Minus: Praktisk bøvl og dumme spørgsmål.

Godt, det var JavaOne 2010: Nu videre til fest og restitution!

Først og fremmest super lækkert at komme ind i et lokale hvor der er aircondition efter en tur i saunaen til “A brief introduction to Scala”.

Sessionen startede med en hurtig gennemgang af hvordan GC’en arbejder med at marker hvilke objekter der er live (Runtime stack refereret objekter).

Myter:

• Malloc/free performer bedre end GC – BUSTED
• Reference counting vil løse alle GC problemer – BUSTED
• GC med eksplicit deallokering vil øge hastigheden – BUSTED
• Finalizers kan kaldes så snart et objekt ikke længere har flere referencer – BUSTED
• GC eliminere alle memory leaks – BUSTED
• GC sparer udviklingstid og koster ikke noget – DEL BUSTED
• Osv.

Plus

Meget god idé med at lave myth busting og 2 meget enegergeret speakers, der havde styr på deres GC, men de har jo også selv kodet den . Fint start med at gennemgå GC’s arbejdsmetoder så eventuelle uklarheder var på plads inden de gik i gang.

Og en lille kvik bemærkning fra de 2 speaker var: At man nok ikke skal kode et styresystem til en atomreaktor i Java.

Minus

Dog syntes jeg at de lige manglede at sprænge noget i luften for at være rigtige mythbusters.

Over and out fra San Francisco.

Indlægget blev holdt af Alasdair Nottingham fra IBM og Aries projektet (han er en af de originale proposal comitters).

Den bedste OSGi 101 jeg har set her på konferencen (jeg har set 2 andre). Ydermere kom han ind på at classloading i OSGi verdenen er MEGET hurtigere end standard Java SE, da den har global classloader, der skal søge alt igennem for at finde en klasse.

OSGi tilbyder “internals” packaging, således at man kan lave refaktorering uden at ødelægge API kompatibiltet.

OSGi Enterprise Specifikation (OSGi ES)

• Smelte Java EE og OSGi sammen (endeligt)
  • Web Apps – Servlets + OSGi
  • JPA
• A la carte model (du behøver ikke bruge det hele/du behøver ikke som OSGi implementor ikke implementere det hele).

• Blueprint Container
  • Spring-derived component model

OSGi ES gør det meget nemmere for operators (drift) – det var lidt tyndt og måske bare en pointe han prøvede at presse igennem.

Demo!!! (baseret på eclipse og de gratis OSGi plugins fra IBM Rational ® – se eclipse marketplace).

Her lavede han fra bunden en Blog Web App “the OSGi way”, og forklarede undervejs- det gjorde han rigtig godt, med et JPA baseret bundle til håndtering af persistens (beware of persistence.xml – den skal man stadigvæk lave, men nu med sær OSGi syntaks).

Det der Blueprint Container halløj er virkelig super svedigt, og jeg tror at fremtiden for Java EE (og også lidt for Spring) ligger i det her OSGi giftemål. (Så kan det godt være at Rod Johnson og hans diciple har haft ret hele tiden med deres Spring DM Server, og de andre bare kan lære det). Det er møg nemt at lave services og bundles, og bruge dem fra andre med det har OSGi ES og Blueprints.

Apache Aries og OSGi runtimen var integreret i eclipse, så når han lavede ændringer, skulle han bare skrive update [n], så sørgede runtimen for at reloade bundles der var rettet osv. (mega hurtigt iøvrigt), super cool.

Jeg tror også at Grails m.fl. nede af vejen burde OSGi baseres (mindst som en option), så vil der nemlig være styr på dependency management, så dependency resolution (det som idag tager super lang tid), skal ske fordi man retter i et taglib.

Plus: Virkelig god demo og forklaring som gjorde at man virkelig forstod det.

Minus: Lamme spørgsmål fra en del deltagere, som helt have misforstået emnet.

Over and out JavaOne (review of conferrence to come later..)

Taleren havde ikke nogen speciel relation til dem der står bag Scala men er i bund og grund bare bruger af sproget og han ville så dele et oplæg som han har holdt en gang før i houston 2009.

På ægte funktionsprogrammeringslektor ørken facon, krydret med små forsigtige og mindst lige så tørre humoristiske udfald fik sessionens taler kørt os igennem basic scala

Det var sådan set fint, vi fik lige gennemgået de mest basale ting ved Scala såsom

• Funktionsprogrammerings koncepter i Scala
• Immuterbar vs. Muterbare objekter.
• Type hierarkiet
• Actors
• Tuples
• og diverse småting.

For mig var det en ganske fin indføring i sprogets basale kunnen, så alt i alt en god session.

En tyk mand i grimt tøj skulle nu fortælle om hvad det var GridGain havde lært på den hårde måde… Han talte rigtig svært forståeligt engelsk (han er founderen af GridGain).

Faktisk kan man downloade GridGains eksempler (de har beholdt både de gamle og selvfølgelig de nye), så man kan sammenligne Java koden med Scala – super cool.

Den tykke mand vandrede hvileløst rundt på scenen, hvilket knirkede og larmede helt vildt – så stå dog stille mand!

Han gennemgik i starten Functional Programming (FP) 101, hvilket han gjorde super godt – så alle kunne være med, og forskellene til Imperativ Programming (IP).

• Java + FP = Post Functional System
  • Java is imperative OO system
  • Jva + FP – Garbage = Scala
• Pure FP languages suck in object domain desing
  • OO is way better in describing our world
• FP excels at actual codeing of the algorithm

• Post Functional “manifesto”
  • Use OO to build your classes
  • Use FP to implement their methods

Lesson: Du kan prøve et FP library, men du ender faktisk med at skrive mere kode (casts, annonyme inder klasser osv.), så stay away from lambdaj osv. Scala rules.

Brug type aliases (typedefs) så din kode biver kort og concise.

Så gik vi til kode eksempler som var Java??? Altså deres eget FP style library til Java. Vi blev så ved med at se eksempler på dette. Det var da interessant, men mange af tingene er jo vist 200 gange. Derefter blev det også noget rodet.

Immutability Actually Works – Brug det! CPU og hukommelses ineffektivitet er meget overdrevet.

De havde brugt predicates, således at de kunne lave et predicate som tog en node (i deres grid/cloud/cluster) og fandt ud af om f.eks. CPU forbruget var under 20%. Den kunne de så kalde en closure på som udførte en funktion på noden. Det er super smart da det så er dynamisk (og dynamiciteten ligger i FP), således at hver gang de kaldte denne function, ville den finde det subset af noder hvor predikatet var sandt, og sætte dem til at lave noget.

Han reklaremede for Tuples i Java, men det er bare så grimt. Jeg er ikke sikker på jeg er enig. Jeg har været nede af Pair, Tuple3, Tuple4 ruten (det han havde lavet var jo typestærke tupler). Tupler er i mine øjne Maps eller Object[], eller rigtige POJOs. Ellers er der noget mærkeligt ved ens program. Dette er selvfølgelig løst elegant i FP.

Så var der lige en til, nemlig at han var stor fortaler for checked exceptions (http://www.mindview.net/Etc/Discussions/CheckedExceptions), men det virker som bekendt ikke i functional style Java.

Alt i alt var det faktisk temmelig interessant, men en noget rodet affære. De vil dog nu flytte til Scala 100% i fremtiden – og så er GridGain OSS til inspiration.

Han vil ikke have at det kaldes et “scripting language” – det undrer ham, for Scala er jo statisk typet.

Resten af gennemgangen var fin nok, men ALT for langsom, for tør, for kedelig. Han vidste hvad han lavede, men … ikke nok Jazz.

Plus: Nu MÅ jeg tage mig sammen og prøve det i praksis.

Minus: Dårlig taler. Simpelthen.

DSL’s kan jo også laves i XML, men det er nok ikke så brugervenligt.

Rich (DSL proponenten) viste nogle uddrag fra DSL’er og viste hvor skræmmende meget Java, der skulle til ellers. Så ville Jaroslav Tulach (API proponenten) træde til og forbedre det, sikre typecheck, fjerne gentagelser, etc.

Modsat viste “den anden gut” hvordan man med annotation processoren kan generere kode on the fly som sikrer en kompakt og typesikker måde at skrive sin Java kode på. Og det har han ret i.

Konklusionen: DSL’er er særligt vigtige når man skal adressere et andet publikum, med andre forudsætninger. Gode APIer og interne API har et andet publikum – udviklere.

De viste gode eksempler på versionering af DSL’er m.v.

Versionering af API’er blev derimod lidt mere langhåret – deprecated, selvfølgelig, men også @Transformation og @PatchByteCode – uha, uha.

Så er der IDE hjælp – Jaroslav fremhæver  at gode Java IDE’er kan alt det gode med annoteringer, etc.

DSL gutten fremhæver at IDE’erne også har gode sprog-toolinger – men de undlod elegant at fremhæve Eclipse’s XText. En spørger klarede dette.

Plus: God diskussion.

Minus: Manglende fokus på “fluent” interfaces, som jo også kommer tæt på.

Manden mente at det var en super idé at externalisere så meget sikkerhed som muligt fra applikationerne. Set ud fra enterprise-apps og konsolidering giver det vel meget god mening, men budskabet ligger skræmmende tæt op af at at tro man kan klistre sikkerhed på bagefter. Er det nu en god idé?

I praksis var hele hans tale ret enterpriseorienteret. Han benyttede straks lejligheden til at så tvivl om sikkerheden i OAuth og OpenID.

Det var på det tidspunkt jeg var vis om at jeg IKKE var det rigtige publikum her? SAML i WebServices, STS, etc. er bare ikke nyt.

Lidt efter lidt blev det klart hvorfor han mente at man skulle klistre sikkerheden på: Det viser sig at Oracle har et produkt hvor man kan sætte sikkerthedsagenter op rundt omkring som kan klistre sikkerheden på bagefter! Sikke. En. Overraskelse.

Plus: Han talte OK engelsk. Sortof.

Minus: Salgsgas, salgsgas. Min fejl at tilføje sessionen ud fra titlen alene. Jeg vil dog mene at man (i et alternativt univers?) kunne have haft et spændende indlæg med den titel.

Der er under Eclipselink hatten både en JAXB runtime med udvidelser (Moxy) og en SDO runtime.

Plus: Dygtig mand, der forklarer ud fra den teknologi, han selv har bygget.

Minus: Når alt hvad man har er en hammer…