Mats Henricsons blog - Java category

Technology stressed? Perhaps it is time to panic!

Thu, 04 Jun 2009 19:10:15 GMT

Four years ago I spent a few months assembling a rather wide-spread document which I named "State of the art in Server Side Java". It was at the time well researched enough to end up as an entry on The Server Side.

Soon thereafter I got sidetracked to follow Ajax for a few years. I even went as the only Swede to the first ever Ajax conference in San Francisco, and blogged a lot from there.

These days there are simply so much things going on in Server Side Java land to have a slight clue as to where that freight-train is heading. There's Hadoop and all its cousins for distributed computing, Actors, Terracotta, a school of new whacky persistence paradigms, a handful of JVM-based languages that only Ola Bini has the energy to follow. Annotations have, as I predicted, totally changed the way we program, and just about every day I bump into a new annotation I've never seen before (yesterday it was @PathParam).

It would feel OK if this plethora of technologies were somewhat obscure, but in my current project we use a lot of stuff I don't know well enough, such as Maven, Jersey, WebLogic, Spring transactions and JPA, just to mention a few.

And even though the Ajax anarchy has somewhat collapsed into a few leaders, such as jQuery, Dojo, DWR and GWT, the whole arena is just all over the place. I've stopped following Ajax these days, there is just too much going on.

So, what do I spend time on, if I don't stay up-to-date with server side Java or Ajax? Well, I'm swamped by RSS and Twitter. I abuse technology news like a drug addict, and believed I was reasonably knowledgeable, until I read this blog post yesterday which listed 14 technologies to follow at JavaOne. I had heard of 3 of them, which made me start thinking.

What the heck is going on? Is this technology race accelerating, not just at the rate of the SW industry expanding, but at a pace where it is getting out of control? Have humans triggered the singularity themselves, without the need for a Super Intelligence? Well, perhaps not. The slice of knowledge any human can follow has been shrinking constantly for a long time. But I can't help getting this idea that the explosion of open source software is giving us the shoulders of giants we can stand on to accelerate our knowledge. And more of it is coming from unexpected countries. Recently I bumped into Debasish Ghosh. Following this guy from India on Twitter is like riding a rollercoaster - new exciting stuff all the time.

So, should we panic? Should we give up? Will every future job search have a list of required skills from a potential list of skills so huge that nobody will ever have a full set? What if we go with maximum speed into polyglot programming, and fragment even further in all directions? Today I heard about two sites where they used Clojure on the server, with Rails as UI. Who the hell can fill that skill set?

Java 7 update från Alex Miller

Mon, 16 Feb 2009 15:18:14 GMT

Alex Miller har precis bloggat om vad han tycker verkar ske när det gäller Java 7. Vi kan få en preview till JavaOne 2009 (dvs juni) och ett teoretiskt releasedatum på januari 2010, men Miller tycker det är för mycket osäkerheter för att tro på en så pass snabb release.

Generellt sett så tror jag han verkar tycka att det ändå blir en rätt intressant release, trots att den inte kommer att ha closures. Man kan tro att jag har massiv kritik mot Sun och Java 7 utifrån rubriken på den artikel i Computer Sweden där jag citeras, men så är inte fallet. Jag tror väldigt mycket utmärkt mjukvara kommer att kunna utvecklas i Java 7 utan dessa closures.

10 really lousy commandments for Java Developers

Sat, 31 Jan 2009 22:30:27 GMT

Aleksey Shevchenko have on developer.com published 10 commandments for Java Developers, and they are of such lousy quality that I just have to respond (this vaguely resembles a xkcd cartoon :-). His commandments are:

Add comments to your code
Do not complicate things
Keep in Mind – "Less is more" is not always better
No hard coding please
Do not invent your own frameworks
Say no to Print lines and String Concatenations
Pay attention to the GUI
Always Prepare Document Requirements
Unit-test. Unit-test. Unit-test
Remember – quality, not quantity

Lets have a meta discussion about programming guidelines. In my not so humble opinion, they must fulfil at least these requirements:

Programming guidelines must be relevant. None of the commandments above have anything to do with Java. What was he thinking?
Programming guidelines must be helpful. Take "No hard coding please" as an example. How the hell is that helpful?
Programming guidelines must stand on their own in one or two sentences. As an example, "Remember - quality, not qualtity" is just sloppy wabbly gibberish. It does not help me at all in my day-to-day programming.

If you feel like writing commandments, better make damned sure they are important. First, is the issue you are adressing severe? If so, is it common? It has to be both severe and common to grant status as commandment. Is "No hard coding please" among the 10 most important programming problems we're wrestling with in Java-land? No. It is at most annoying, and can easily be refactored.

After frothing at the mouth like this, lets go into details:

Add comments to your code.

My reaction is that this is just the wrong way to go. Instead extract methods with names describing what is going on. If you've added a comment, such as "Calculate interest rate according to RFC 666", extract the relevant code into a function named calculateInterestRateAccordingToRfc666(). Much better!

Do not complicate things

I feel like using the cane to punish such useless meaningless drivel.

Keep in Mind – "Less is more" is not always better

Have a look at the original examples and ask yourself, what is the correct thing to do? My suggestion is, again, to extract a function, and use constants.

No hard coding please

To be helpful he should have written "Literals should only be used in the definition of constants and enumerations".

Do not invent your own frameworks

Yes yes yes, but what has this to do with Java?

Say no to Print lines and String Concatenations

Is this important? Is it common? If so, you really have a serious problem.

Pay attention to the GUI

Well, what can I say? Aleksey have realized that "The GUI is an essential part of a successful application". What can I say? It seems... profound!

Always Prepare Document Requirements

In the description he elaborates thus: "Every business requirement must be documented." This guy seriously needs to be hit by the 26 ton agile bus.

Unit-test. Unit-test. Unit-test

TDD, TDD, or BDD, BDD. Much more important than unit tests.

Remember – quality, not quantity

Has he stumbled upon something important here? No, I will, as always, prefer quantity over quality every day of the week. Code is an asset, as well all know. The more the merrier!

As a warning to anyone with a severe case of Moses complex out there, think again before you start whacking away with chisel on stone.

Actors Galore

Sun, 11 Jan 2009 16:20:15 GMT

När jag började lära mig Scala så stötte jag direkt på Actors, ett koncept snott från (om jag förstått det hela korrekt) Erlang. Actors är ett sätt att få till concurrency genom att skicka meddelanden, till skillnad från det vi alla under ett decennium svettats med i Java, trådbaserad concurrency. Tanken är att det ska vara ett lättare sätt att programmera inför den multi-core framtid vi står inför.

Att skriva om sin applikation så att den kan hålla ett par kärnor varma låter sig kanske göras, men hur ska en vanlig applikation rimligen få mer än en handfull kärnor att komma över rumstemperatur?

Så kom Kilim, och jag gjorde ett försök att skriva ett enkelt exempel, men min förståelse för hur Kilim fungerade var för ytlig för att jag skulle ro det hela iland. Jag försökte skriva om min primtalsberäknare från JavaSpaces till Kilim, men det visade sig att att ha en master och många workers inte är det gängse sättet att använda sig av actors.

Nå, för en dryg vecka sedan bloggade Sujit Pal om alla de Actors-ramverk som nu dykt upp som svampar ur jorden. Han har fungerande kodexempel för Kilim, Scala Actors, samt Jetlang, ActorFoundry och Actor's Guild (hehe, fyndigt namn)! Har man en gång utvärderat ett bleeding edge ramverk av den här typen så inser man vilken herkulisk insats han har gjort för att utvärdera fem ramverk!!

Om man detaljstuderar exemplena så ser man en del eleganta detaljer, men också för varje ramverk en del som ger mig lite ont i magen och gör att jag slipar tänderna mot varandra med ett ohälsosamt ljud. Med lite tur sätter sig de olika programmerarna samman och gör en AOP, dvs mergar sina respektive ramverk på samma sätt som AspectWerkz (drivet av en av våra svenska superprogrammerare Jonas Bonér) och AspectJ slog sina påsar samman och skapade den industristandard som vi nu åtnjuter.

Vad kommer egentligen i Java 7?

Tue, 16 Dec 2008 20:24:45 GMT

Alex Miller har haft den intressantaste bloggen för de som intresserat sig för Java 7, och han har en speciell sida där han summerat all information han kommit över.

Java har känts lite övergivet på Sun, tycker jag. Det har inte funnits någon kapten på skeppet. Gosling gör lite som han vill, men driver inget på egen hand som har med Java att göra, verkar det som. Neil Gafter jobbar nu för Microsoft (burr), och Josh Bloch har bytt till Google. Kvar på Sun fanns Gilad Bracha, mannen med den bästa titeln - Computational Theologist - som hade sitt eget språk han snickrade på, Newspeak. Han blev också lockad över till Microsoft, och min gissning var att han blev ditlockad av att få en grupp som kunde driva hans språk framåt. Nå, Microsoft hoppade av, och jag vet inte vad han sysslar med nu.

Kvar på Sun finns Danny Coward. Vet inte om han har karisma och guts nog att driva fram Java 7 med den pondus som behövs. Ett språk behöver en järnhand för att drivas fram i rätt riktning, tror jag.

Hur som helst så har Alex Miller nu gjort en ny gissning av vad Java 7 kommer att innehålla. Inga closures, vilket många tycker är konstigt, med tanke på all den brouhaha som genererats under den rubriken de senaste åren. Jeez. Hur som helst är det rätt intressant läsning!

Cascading - MapReduce without the complexity

Thu, 25 Sep 2008 20:21:00 GMT

Just bumped into Cascading, which is an open source (GPL 3) framework "for defining and executing complex and fault tolerant data processing workflows on a Hadoop cluster". Hadoop is, I'm sure you all know, an implementation of MapReduce which is at the core of how Google does its processing.

Anyway, the Cascading API "lets the developer quickly assemble complex distributed processes without having to "think" in MapReduce", which can get really complex in non-trivial applications.

What is SpringSource doing with its license?

Tue, 23 Sep 2008 21:46:00 GMT

It appears as if SpringSource, the company doing most of the development of Spring, is doing an ExtJS, i.e. changing the license of its product to force users into paying for it, or its support. Lots of people are writing about this, such as Alessandro Santini at JavaLobby. Does anyone have any enlightening comments?

Regardless, I think it is now up to the community to start asking the maintainers of various emerging frameworks explicitly if they in the future will change its license. If they slipper and slide on the answer, then we know we're in for a rough awakening.

Woohoo: Mixed Scala and Java projects in Eclipse

Sat, 20 Sep 2008 12:47:00 GMT

A few days ago Scala 2.7.2 RC2 was released. One of the new features is mixed Java and Scala support in both the compiler and the Eclipse plugin. I decided to try it out. Installation was very simple. I then set off creating a simplistic Java class side by side with the Scala object, in the same package. I then created such a Java object in my Scala code, and ran it. It just works!

Kilim - Actors for Java

Sun, 03 Aug 2008 22:18:00 GMT

Just bumped into Kilim, an actors framework for Java. This could be really important! The most exciting thing I've seen in several months!

Steve Yegge om hur språkvalet påverkar kodbasens storlek

Tue, 12 Feb 2008 22:52:00 GMT

Steve Yegge, som jag bara stött på vid några tillfällen tidigare, skrev strax före jul ett blogginlägg under rubriken Code's Worst Enemy. Där försöker han, utifrån erfarenheten från ett spel han skrivit på egen hand i Java, argumentera för att det är Javas fel att hans kodbas nu är på 500 000 rader. Vilket han nu inte längre klarar av att underhålla.

Nu kan man ju undra hur en person över huvud taget kan skriva en halv miljon rader Java. Och premissen att det är Javas fel att det är så många rader kan ju också diskuteras. Men jag är nog böjd att acceptera att Java kanske inte är det tightaste språket på planeten. Men Steves beslut att skriva om allt i Rhino känns ju rätt bisarr.

Över huvud taget ska man, enligt min ödmjuka mening (IMHO) tänka sig för innan man börjar skriva ett stort system i ett dynamiskt språk. Dels får man betala detta med "continuous tax", samt att man inte kan få något riktigt solitt refactoring stöd. (Båda länkar går till blog-inlägg av husguden Cederic Beust).

Så min rekommendation, om man är rädd för att begrava sig själv i sin kodbas, är att välja Groovy, där man i alla fall kan slå på statisk typning om man vill, eller Scala som är statiskt typat. Och båda kommer med bra webbramverk i form av Grails och lift. Utan ett sådant är ett språk rätt kört.

Hur som helst så har Steves inlägg genererat en otrolig mängd med inlägg av många rätt kända personer. Har ni några timmar till övers så är det värt en titt.

Ouch, Howard Lewis Ship dumpar Maven

Tue, 29 Jan 2008 11:18:00 GMT

Skaparen av Tapestry, Howard Lewis Ship, dumpar nu Maven, efter att ha använt det väldigt mycket. Citat från hans blog:

The Maven team is criminal...
...

The Maven project site is an embarrassment. The tool supposedly designed for "project comprehension" is itself incomprehensible, due to its scale, the chaos of its documentation, and the extreme lack of engineering discipline evidenced by its maintainers.

Get out while you still can.

Inom Crisp har vi två fraktioner, en som gillar Maven och använder det mycket, och en annan grupp som är skeptisk. Jag hör till den senare gruppen, efter att ha sett ett projekt nästan snubbla på Maven. Dessutom är jag är en stor fan av Hani Suleiman, och han avskyr Maven.

Den senaste tiden har jag sett många projekt gå över till Maven, bland annat är det mycket använt i Scala, och just nu sitter jag på Jfokus och lyssnar på ett föredrag om Apache ServiceMix, och de använder också Maven. Men Ships inlägg gör att jag inte kommer att rekommendera Maven om inte projektet där det ska användas är rätt enkelt i sin struktur.

Terracotta clustering of Scala Actors

Mon, 28 Jan 2008 23:56:00 GMT

I Scala finns ramverket Actors, som ska vara en nära mappning av Erlangs framgångsrika motsvarighet med samma namn: ett meddelande-baserat ramverk för concurrency. Nu har Jonas Bonér kopplat ihop Scalas Actors med Terracotta, vilket ger oss transparent klustring av dessa Actors!

David Pollak, skaparen av webramverket lift för Scala lät hälsa:

This is most awesome news. I'll do some work seeing if we can scale Skittr to 50M users on an EC2 cluster.

Jag har ganska svårt att föreställa mig en häftigare applikation: Scala, lift, Actors, Terracotta och EC2. Ring mig om ni har ett Scala-uppdrag i fickan!

Varför Scala kan vara nästa stora programmeringsspråk

Fri, 14 Dec 2007 00:05:00 GMT

Jag har funderat ganska länge på vad nästa stora språk skulle kunna vara. Jag var tidigt med på resan från C++ till Java. Åkte på den första JavaOne konferensen i San Francisco, och trodde redan då att Java skulle ta över. Så fort det var möjligt lämnade jag C++ bakom mig, trots att jag skrivit en bok om C++ och suttit i standardiseringskommissionen för C++.

Men Java varar inte för evigt, och jag har på egen hand samlat på vad jag tror är viktigt för att något ska bli "nästa stora språk":

Dess syntax får inte vara för olika det som gäller idag, dvs Java, för annars kan man inte få speciellt många att migrera.
Det måste bygga på en virtuell maskin, troligen endera JVM eller Microsofts CLR. De ger den portabilitet vi kräver idag. (CLR är ju kanske inte så portabel, men i teorin finns ju Mono.)
Det måste ha inbyggt stöd för multi-core. Då menar jag inte bara det språkstöd som finns i Java och andra språk för att skapa och starta trådar, utan inbyggt stöd så att virtuella maskinen kan bryta loss delar av det som ska exekveras till olika cores i framtidens processorer. Om 5 år har vi ju kanske 16 cores som standard i en processor, och att manuellt skriva kod som utnyttjar dem är för svårt för annat än experter.
Det måste ha stöd av ett stort företag som kan ställa upp med resurser att skriva verktyg, bibliotek, marknadsföring, konferenser, böcker, etc.
Det måste ha bra prestanda. Visst, Javas prestanda var inte bra från början, men det fanns inget skäl till att det skulle behöva vara långsamt, och idag har Java väldigt bra prestanda, förutom startup tid.
Det bör helst inte överge tidigare investeringar i redan existerande kod.
Det bör vara statiskt typat, för annars blir det svårt att bygga bra verktyg för bland annat refaktorering, vilket är nödvändigt för större projekt.
Det måste vara objektorienterat - det är otvetydigt så att det är det paradigm som fungerat bäst för att bygga stora system.

Java har idag allt detta, förutom 3, och det oroar mig en del. Så fick jag höra talas om Scala och dess ramverk som heter Actors. Det hävdades att det skulle hjälpa till med just detta med multi-core. Har ännu inte läst in mig på just Actors, men jag blev nyfiken på Scala och läste in mig på det.

Scala är ett statiskt typat objekt-orienterat språk med en syntax som är tillräckligt lik Java för att man ska luras att ta en närmare titt. När man väl sett på vilket sätt det också är ett funktionellt språk, med dess annorlunda syntax (som jag tror måste till av ren nödvändighet för att ge ett sådant stöd), så har man redan svalt kroken, sänket och hela korken.

Scala ligger ovanpå Javas virtuella maskin, och Java-klasser kan användas rakt av. Java-kod är inte automatiskt giltig Scala-kod, på det sätt som all C för 15 år sedan var giltig C++, men man kan ta med sig existerande Java-kod in i den Scala kod man skriver.

Tyvärr har inget större företag ställt sig bakom Scala ännu, men det finns riktigt många projekt som jobbar på verktyg och ramverk. Det finns en rätt bra Eclipse-plugin, ramverk för enhetstestning, ett mycket intressant webbramverk som heter lift, en mycket aktiv och hjälpsam mailinglista, och ett par böcker på gång. En av böckerna kan man precis förbeställa!

Scalas prestanda är mycket bra, kan till och med med vara snabbare än Java.

Här står jag själv just nu. Jag ska läsa den nya Scala-boken över julhelgen. Just nu är jag mest en entusiastisk amatör som tror jag hittat något som kan bli riktigt stort.

JAX-RS: RESTful Web Services

Mon, 29 Oct 2007 22:18:00 GMT

Draft specen för JAX-RS: The Java API for RESTful Web Services släpptes för någon vecka sedan. Som oftast brukar jag inte orka granska specarna som kommer, men denna gång tog jag mig en titt. It made me go mmmm... som det heter. Kan denna lilla kodsnutt väcka aptiten:

@UriTemplate(“widgets”)‏
public class WidgetList
{
   @HttpMethod
   @UriTemplate(“offers”)‏
   WidgetList getDiscounted() { /* ... */ }

   @UriTemplate(“{id}”)‏
   Widget findWidget(@UriParam(“id”) String id)‏
   {
      return lookupWidget(id);
   }
}

Här är en annan goding:

@UriTemplate(“widgets”)‏
@ProduceMime(“application/widgets+xml”)‏
public class WidgetList
{
   @HttpMethod
   String getAll() { /* ... */ }

   @HttpMethod
   @UriTemplate(“{id}/description”)‏
   @ProduceMime(“text/html”)‏
   String getDescription(@UriParam(“id”) String id) { /* ... */ }
}

Men, gräver man djupare i specen (den är hittills bara ~30 sidor) så blir det mer hmm... än mmm... massor av rätt märkliga begrepp som jag aldrig stött på tidigare. Speciellt begreppet Contract i detta sammanhang förvirrar mig ganska mycket. Hur som helst, väl värt en titt. Kanske en RD på ämnet?

Detta har hänt i sommar

Wed, 15 Aug 2007 19:21:00 GMT

För er som inte knarkar tekniknyheter lika okontrollerat som jag gör har jag nöjet att få summera de senaste 5-6 veckorna inom områdena Java, Ajax, Scrum och annat av intresse. Tro mig, jag har gallrat stenhårt.

JUnit 4.4 släpptes nyligen. Nyheterna var inte speciellt upphetsande.
En av mina favoritbloggare, Cederic Beust, har skrivit om dynamiska och statiska språk. Inte mycket text, men mycket intressant. Väl värt ett par minuter.
Av någon anledning är kodformattering mig nära hjärtat, så det var med visst nöje jag noterade att Slashdot hade en tråd om detta i somras. David Herron har bloggat i samma domäner, vilket är kul, även om han verkar ha snott titeln på sitt inlägg från mig.
Medlemmar från Ajax-ramverket Dojo har skrivit en artikel med namnet "Why Dojo", som jag tror alla som står i valet och kvalet att välja Ajax-ramverk nog bör läsa. Dojos event-modell är väldigt cool, och tydligen har den blivit extra bra i senaste 0.9 versionen av Dojo.
En annan Ajax-artikel med namnet "Write scalable Comet applications with Jetty and Direct Web Remoting" borde intressera alla som försöker välja Comet-ramverk. Go DWR Go!
ThoughtWorks har släppt en "agile project management software" med namnet Mingle. Vet inget mer om detta, men Henrik kanske känner sig manad?
Matt Raible har summerat "Open Source Web Frameworks' Mailing List Traffic - June 2007", dvs hur mycket trafik är det på de olika ramverkenas mailinglistor. Ganska intressant, om man försöker avgöra vartåt det blåser. Till min stora glädje ligger Wicket bra till, Liksom GWT, men mest trafik har Ruby on Rails, vad man nu kan dra för slutsatser av det?
W3C funderar på att inte låta HTML 4 övergå till XHTML, eftersom de verkar vilja göra en femte version av HTML. Vad ska man tro om det?
Specifikationen för Java EE 6 har släppts. Troligen kommer de första implementationerna först i början av 2009.
Jag försöker hålla ett öga på vad som skrivs om Scala, då jag fått intrycket att det kanske är ett bra språk för framtidens multi-core processorer, så artikeln "Is Scala the new Groovy" kunde jag naturligtvis inte undvika. Sedan finns det de som tror att Terracotta är rätt väg att skriva multi-core applikationer i Java, så "Hello Terracotta" kanske är rätt ställe att börja?
Vill man läsa mer om JavaScrips framtid så kan man läsa här. Daniel?
För oss anhängare av Google Calendar är nog artikeln "Black belt scheduling with Google Calendar" oundviklig.
Vad kommer efter social networking? Själv har jag inte en aning, eftersom jag känner mig helt bakom flötet när det gäller Facebook, YouTube, MySpace, Twitter, etc etc etc.

Privat har jag varit en vecka i Småland, 4 veckor i Thailand, samt en vecka i Västerbotten, där jag och mina två söner besteg fjället Jengegietje, 1477 meter över havet, i lysande väder. Shorts och T-tröja räckte på toppen!

Om att parsa CSV filer

Tue, 03 Jul 2007 10:09:00 GMT

Att parsa CSV (Comma Separated Values) kan tyckas trivialt:

Bananer,3,22.30

Men om man vill tillåta komman i värdena, så blir det inte lika roligt:

Bananer,3,"22,30"

Jag browsade runt lite på nätet och fastnade för opencsv. Det är

Open source
Väldigt litet (2 klasser, en JAR fil på 16 KB)
OK dokumentation
Version 1.7, dvs inte beta
Utvecklaren har en aktiv blog
Populärt (ca 50 nerladdningar per dag på SourceForge)

Som genom magi fick jag samtidigt ner en lista på de kriterier jag använder när jag utvärderar ramverk! :-)

XX Framework - ett nytt webbramverk för Java

Tue, 03 Jul 2007 09:59:00 GMT

Eller nytt och nytt, har funnits i ett drygt år, verkar det som, men jag har aldrig hört talas om det förut. XX i XX Framework står för XML och XSLT.

The primary goal of the XX Framework is to handle typical application CRUD (create, retrieve, update, delete) with little or no Java programming. Instead of telling the application how to retrieve and how to display the data, we configure what to retrieve (through XML) and what to display (through XSLT).

Inget om man har aversioner mot XML, tydligen, men kanske helt rätt om enkel CRUD är ens sweet spot. Fast då kanske man ska använda Trails istället?

Kanske är det Scala?

Sat, 23 Jun 2007 22:33:00 GMT

Jag har tidigare bloggat om vilket språk som kanske kan ta oss med i multi-core racet. Erlang skulle kännas som ett nederlag (några av er kanske förstår varför). Ruby hypas ofta som nästa stora språk, men är det något att hålla i handen när man surfar loss på flera cores? Jag tvivlar, av ren princip, utan att egentligen veta. När ska man få vara ologisk och partisk om inte vid valet av nästa språk att riskera sin karriär på?

Så nyss bankade jag pannan i en artikel skriven av Bill Venners, Martin Odersky och Lex Spoon med namnet First Steps to Scala. Inledningen är mycket intressant:

Scala is a statically typed, object-oriented programming language that blends imperative and functional programming styles. Scala is designed to integrate easily with applications that run on modern virtual machines, primarily the Java virtual machine (JVM). The main Scala compiler, scalac, generates Java class files that can be run on the JVM. However, another Scala compiler exists that generates binaries that can be run on the .NET CLR, as Scala is designed to integrate with both the Java and .NET worlds. In the Java world, the Scala language can be used alongside the Java language—either as an alternative to Java—to build applications that run on the JVM.

Scala was developed starting in 2003 by Martin Odersky's group at EPFL, Lausanne, Switzerland. Previously, Martin had been active in the Java field. He co-designed the first version of Java generics and was the original author of the current javac compiler. The work on Scala was motivated by the desire to overcome limitations imposed by backwards compatibility with Java. So Scala is not a superset of Java, but it retains seamless interoperability.

Mmmm, kanske en Rocket Day om detta i Crisps regi?

Spring Batch ser lovande ut

Sat, 23 Jun 2007 22:20:00 GMT

På mitt nuvarande uppdrag hos Keybroker har vi skapat ett rätt avancerat batch-processing ramverk, byggt på Spring och Quartz. Nu verkar det som om Spring håller på att bygga ett eget sådant ramverk med namnet Spring Batch. Deras arkitektur ser lovande ut, men tyvärr finns inte så mycket på plats ännu.

Egentligen ser jag detta som ett misslyckande för Quartz, för det var länge sedan jag stötte på ett ramverk som var i så desperat behov av en arkitekturell översyn. På ytan ser det enkelt ut, men ju djupare man dyker i dess features, ju mer desperat blir man. Den nya RetryPolicy klassen ser ut att kunna ta bort orsaken till mycket av den tandagnisslan jag tvingats göra den senaste tiden.

Characteristics of a Good DAO

Tue, 29 May 2007 07:54:00 GMT

Eric Burke har i sin blog skrivit ner 13 saker man bör tänka på när man skriver sina DAO (Data Access Object) klasser. Det verkade vara en bra sammanfattning, tyckte jag.