1. namnet java

    på en skärgårdsbåt i helgen stötte jag på en bekant från förr och vi uppdaterade varandra på vad vi sysslar med numera. jag berättade att jag arbetar som javakonsult och samtalet gled in på vad namnet java betyder och var det kommer ifrån. javaloggan innehåller ju en kaffemugg; har java tagit sitt namn från kaffesorten eller ön Java eller både och, eller från ön fast via kaffesorten. men om namnet är taget ifrån kaffesorten, hur kommer det sig då att det java-relevanta opensource-projektet jakarta, som ju också är namnet på en stad på ön Java, har fått just namnet jakarta. kommer kaffesorten Java från ön Java? eller är java dessutom en förkortning för något?

    ok, enligt javaworld valde sun namnet Java för att det är en ”kaffe-metafor” (!). tja. metafor enligt wikipedia:

    ”Metafor, ett bildligt uttryckssätt där ett begrepp tillfälligt byts ut mot ett begrepp som liknar det ursprungliga.”

    alltså är ex ordet villaprisbubbla en metafor men jag ser inte hur namnet java skulle vara en kaffemetafor för ett programmeringsspråk eller plattform. visst, java är dynamisk, revolutionärt och roligt, men har kaffe dessa egenskaper?

    jakarta då? en uppenbar kaffe->programspråk->geografisk-metafor man tycka, men faktiskt är svaret något annat. enligt wikipedia döptes opensource-projektet jakarta efter ett konferensrum och inget annat:

    ”A frequent question in discussions related to Jakarta regards the origin of the name. Jakarta is not directly named after the capital city of Indonesia (which happens to be located on the Java island), nor after the Jakarta blue butterfly species. Instead, it is named after the conference room at Sun Microsystems where the majority of discussions leading to the project’s creation took place.”

    på båten trodde jag att det finns fler java-relevanta projekt/mjukvaror med namn från området kring ön java, men nu när jag letar efter detta på nätet så blir jag osäker…

  2. REST – Vad är det?

    I webbservicevärlden har det pratats om REST en del. REST som ett annat sätt att presentera webbservices än SOAP och hela WS-*-stacken med protokoll och specifikationer.

    Jag har för avsikt att i ett paper eller inlägg lite senare gå igenom skälen varför REST kan vara bra. I en framtida presentation jag ämnar hålla, så ska jag dessutom visa hur man kan göra.

    Men, slog det mig just, då måste jag ju först säga vad det är, eller hur?

    Nå, till att börja med är det ingen teknisk standard. Det är inget protokoll. Det är ingen applikation. Och det är inte ens ett alternativt SOAP. Framförallt är det inte ett alternativt SOAP.

    REST är ett designmönster.

    Applikationer skrivna utifrån REST-mönstret löser ungefär samma saker som applikationer skrivna med SOAP gör, fast ibland bättre, (och då per design bättre).

    Det applikationsprotokoll som används är först och främst HTTP. Inte som SOAP, som använder HTTP som ett transportprotokoll, och som i teorin skulle kunna använda helt andra protokoll. Nej, vad REST handlar om är att använda HTTP som applikationsprotokoll i sig själv.

    Vad det innebär kan du läsa i min nästa post.

  3. Nästa Javaforum 23 maj

    arrangeras som vanligt av IBS JavaSolution. Denna gång blir det bland annat rapport från JavaOne ‘07, XFire, eXist, Rest, godbitar från SUN. Vi avslutar med JavaPub sponsrad av SUN!

    Anmälan på javaforum.se

  4. De största och vanligaste misstagen med XML (del 1)

    XML har idag funnits som en standard i lite mer än 9 år (publicerades den 10:e februari 1998). Jag har själv varit en stor anhängare av att använda XML till allt möjligt, ibland kanske i en lite för stor utsträckning. Oavsett vad man anser om XML så är standarden här för att stanna och vi kommer dras med i en lång tid framöver. Problemet är bara att utvecklare inte är helt på det klara med vad XML faktiskt är för något. Detta leder ofta till att man stöter på XML som används felaktigt på ett eller annat vis. Efter SQL så är nog XML den standard jag arbetat mest med, så jag tänkte ta upp ett par av de vanligaste misstagen jag stöter på. Jag tänkte återkomma till detta i senare inlägg också, så här kommer det mest allvarliga felet som jag stöter på.

    Encoding och att manuellt skriva XML
    XML är visserligen i ett s.k. ”human-readable” format, eller vanlig text om man så vill. Detta gör att utvecklare ibland väljer att skriva XML med hjälp av vanlig sträng-konkatenering istället för att använda ett befintligt XML API, särskilt om det bara är en XML-snutt som enkelt ska skickas ut på en webbsida eller dylikt. I princip är ju det samma sak som XML APIerna gör, så varför kan man inte göra det manuellt om man bara ska ”slänga ihop” något snabbt? Visst, vet du vad det är du gör så är det ju inte fel, men problemet är att man oftast glömmer bort viktiga detaljer, något som kan få allvarliga konsekvenser längre fram. Ett väl-formulerat (well-formed enligt XML specifikationen) behöver visserligen ingen XML-deklaration (första raden i XML som har formatet: ), men om inget sådant finns så görs vissa antaganden. Den encoding som används är vanligen det som orsakar störst bekymmer när man manuellt skriver XML. Anger man ingen XML-deklaration med ett encoding-attribut så antas det att det är UTF-8 eller UTF-16 som används (vi går inte in på detaljerna för dessa här, kolla XML specifikationen för detaljer).

    Säg nu att du i Java skriver XML manuellt och att du sitter i Windows när du skriver. Nu kommer din XML följa den encoding som används i Windows, vilket betyder CP1252 för oss här i Sverige. Om du nu inte angett encoding så uppstår problemet när XML-dokumentet ska läsas in igen, eftersom en XML-parser ska anta att det är UTF-8 eller UTF-16 om ingen encoding angetts. I de flesta fall är inte detta något problem, eftersom ASCII är ett subset av UTF-8 och CP1252 mappar de flesta tecken till samma bytes som ASCII. Men när du använder något tecken utöver de första 127, t.ex. å, ä eller ö, så kommer det bli problem. Detta är anledningen till att du får ibland inte får se svenska tecken korrekt i ett XML-dokument. Ni har säkert stött på detta på vissa webb-sidor där å, ä och ö förvandlas till något helt annat. Kort sagt, skriver du XML manuellt så måste man tänka på att skriva XML-deklaration och använda rätt encoding. Eftersom det inte alltid är helt lätt att komma hålla ordning på detta (skriver du med en OutputStream eller Writer i Java så används operativsystemets encoding om inget annat anges, så du kommer ha olika encoding från samma program beroende på vilket OS du kör på) så är det alltså säkrare att använda ett XML API för att skriva din XML.

    Nästa gång; taggar, attribut eller tecken, vad ska man använda egentligen?

  5. Mobilapplikationer i verkligheten

    Jag har de senaste veckorna arbetat med en ny tjänst för mobiltelefoner (ett uppdrag jag tagit över efter min kollega Mikael). Som ni förstår så är det alltså Java Microedition som det hela byggs i. Nu var det ett tag sen jag kodade något i Java ME på riktigt så jag hade glömt en hel del detaljer. Uppenbarligen är det lika illa ställt med Java på mobiltelefoner idag som det var för ett par år sedan. Om du ska skriva en applikation som du hoppas på att många ska använda så behöver den fungera på flera olika tillverkares telefoner, och det är här problemen börjar. För att din applikation ska kunna få göra något mer avancerat än att visa bilder och text så behöver den signeras (ok, den måste inte signeras, men användaren kommer bli nipprig på alla frågor om att låta applikationen göra ditt och datt). Nu tycker man kanske att det bara vore att använda samma signeringsverktyg som finns i Java SE, och i princip ska det vara likadant. Dock har olika mobiltelefontillverkare bestämt sig för att hitta på egna lösningar och metoder för det hela. Att signera en applikation som ska köras på en Motorola-telefon kräver ett speciellt certifikat från Motorola, Samsung vill signera allting själv (alltså, skicka in ditt program till ddem och få tillbaka det ett par veckor senare) och sådär fortsätter karusellen. Den enda telefontillverkare som försökt hålla sig till standarden är SonyEricsson (som för övrigt lyckats följa de olika Java ME standarderna bäst).

    När du väl kommit runt problemen med signering så har vi APIerna som telefonerna hävdar att de stödjer. Ta JSR-234 (Advanced Multimedia Supplements) som kort och gott syftar till att tillhandahålla lite mer avancerade funktioner för media i telefonen. Det finns klasser för 3D ljud, video, kameran och FM radio. Låter spännande, eller hur? Problemet är bara att det enda som mobiltelefontillverkarna valt att stödja i det APIet är kamera-funktionerna, på sin höjd. Om nu telefonen har en FM radio, stöd för 3D ljud och möjlighet att spela upp video, vaför kan jag inte få accessa dessa funktioner i Java ME då?! Såhär är det med många av de mer intressanta JSRer som finns för Java ME. Vanligtvis är det återigen SonyEricsson som har bäst stöd, men det är en ganska klen tröst när de är långt ifrån de vanligaste telefonerna på marknaden (åtimstone utanför Sverige).

    Det känns lite som att mobiltelefontillverkarna (och i viss mån även operatörerna som låser och begränsar enheterna) medvetet sätter krokben för tredjeparts-tillverkare. Idag är det oerhört svårt för en utomstående att få in sin applikation på mobiltelefon-marknaden. Det tråkiga är att Java ME är det enda reellla alternativet, Symbian C++ är ännu värre att koda i och fungerar sällan likadant på olika telefoner och .NET har ett ytterst begränsat stöd på dagens mobiltelefoner. Flash-applikationer hade varit ett alternativ, men det är tyvär fortfarande en alltför begränsad platform.

    Jag hoppas att nästa version av MIDP (3.0) som är på väg kommer lösa många av dessa problem som vi utvecklare stöter på. Dock tror jag att vi även i framtiden kommer behöva slåss både mot mobiltelefontillverkarnas ovilja att följa standarder.

    …och då har jag inte ens nämt hela dramatiken kring DRM-skyddat material och Java ME..

  6. Dra ditt strå till stacken

    Jag har vid flera tillfällen märkt att en del bra open-source projekt dör med tiden. Det är ledsamt men naturligt. För det mesta är det små projekt med någon enstaka eldsjäl bakom som drabbas av detta. När eldsjälen tröttnar eller av någon anledning inte har tid längre finns ingen som kan ta över. Jag stötte på detta senast i helgen när jag tyckte det var dags att uppgradera phpDiveLog som jag tycker är en trevlig webbapp för att presentera dykloggar. Inget har hänt på länge.
    Vad kan man då göra åt saken? Mitt råd är att kavla upp ärmarna och hjälp till. Om fler engagerar sig i alla små fria trevliga utilities förenklas vår tillvaro (eller blir vi datanördar bara nördigare?). Jag började fixa till phpDiveLog för att passa mig bättre men så hittade jag plötsligt jDiveLog (Java!!!) som lever i allra högsta grad och har massor av mer funktionalitet. Detta är väl en orsak till att vissa projekt dör, de konkurreras ut helt enkelt. Men mitt budskap kvarstår: tveka inte att engagera dig – du behövs!

  7. Pusha meddelanden i JME

    JME blir allt populärare och det finns en hel del godbitar som många inte känner till. En sådan är möjligheten att från en applikation pusha meddelanden till tex en mobiltelefon som automatiskt processar meddelandet på rätt sätt när det kommer fram utan att användaren själv måste aktivera något program på telefonen. Denna funktionalitet är en av många nyttiga funktioner i MIDP 2.0 (Mobile Information Device Profile). Intressant? Läs då JavaWorlds artikel om ämnet som finns här.

  8. IBS JavaSolutions på JavaOne 2007

    Till vår stora glädje så blev en av våra förslag till presentationer på JavaOne 2007 godkända. Vi ska nu dit och hålla en session med den preliminära titeln ”Write A 3D Game in Java Technology in Less Than 50 Minutes…”. Syftet är att visa hur enkelt och snabbt man kan sätta ihop ett spel i Java. Nervositeten är hög men ambitionen är högre. :)

    San Fransisco here we come!

  9. Film om Web 2.0

    Dagens film från youtube.com om Web 2.0!