Tag Archives: java

Readable Java system tests with good old JUnit

Posted on by

This article is the third in a series about system testing:

  1. Dockerized testing vs end-to-end testing
  2. How to setup Dockerized testing
  3. Readable Java system tests with good old JUnit

JUnit is poorly named. Given the name, people tend to think that it should only be used to write Java unit tests. And then people feel a bit hesitant about writing their integration tests with JUnit too. When they start with system tests, they often think they need another driver for their tests. Sure, maybe using another abstraction layer and a custom domain specific language (BDD), you can make the tests more readable for a non-programmer. That often comes at the cost of making the tests less readable for the programmers. And if we are honest, who’s going to read the tests the most? Perhaps just naming test classes and methods well and writing readable code can suffice?

read more »

Codekvast soon available as a Heroku add-on

Posted on by

Codekvast is a tool for detecting Truly Dead Code in your Java application.

Truly Dead Code is code that is in production, but has not been used for a significant time.

Codekvast has been lurking in the spare-time realm for too long. Now the project has eventually been granted some full-time development effort, with the initial goal of being made available as a Heroku Add-on.

The alpha test period is just about to start. For this to happen we need YOU!

Read more about how to become a Heroko add-on alpha tester here.

TL;DR Participant must be a Heroku-app written in Java/Gradle, request invite by mailing codekvast-support@hit.se.


Another builder pattern for Java

Posted on by

Whenever you have a domain object, data transfer object, parameter object or any other object that can’t be instantiated with constructor parameters only, you need to create a builder for its class.

The great thing about Java is that it is statically typed so a builder can give you compiler errors if you forget to set the compulsory parameters. If you use the builder in this pattern, you also get a very fluent interface that imposes order on the parameters. When using the builder, your IDE will suggest the next parameter to set.

read more »

Hur man kan hantera Continuous Delivery med MongoDB

Posted on by

MongoDB är en schemalös, dokumentorienterad databas som har fått stor popularitet i den agila världen bland annat därför att man inte behöver underhålla något databasschema.

MongoDBs schemalöshet gör att många leds att tro att Continuous Delivery blir en promenad i parken, eftersom det ju inte behövs några datamigreringar när man driftsätter en ny version av koden!

Rent teoretiskt är detta sant, men är ett sluttande plan in i Land of Crappy Code™ !

För att slippa onödig komplexitet i form av varierande utseende på lagrade domänobjekt beroende på deras ålder, rekommenderar jag att man utför regelrätta datamigreringar även när man använder MongoDB!

Jag rekommenderar även att datamigreringen är en del av applikationen — till skillnad från skript som skall köras vid sidan av innan applikationsstart — helt enkelt för att eliminera risken för misstag.

Jag har i mitt sidoprojekt Varmfront.nu utvecklat en kompakt liten lösning som i MongoDB implementerar det som Flyway gör för SQL.

Mönstret bygger på Spring Data for MongoDB och Spring JavaConfig, och migreringarna är skrivna i Java. That’s right folks, no XML here 😀

Läs vidare, så får du se hur man kan göra!

read more »

Stop the Line – Build Quality In with Incremental Compilation

Posted on by

We in the software industry are still far behind when it comes to automated quality checks. Toyoda Sakichi for example invented the automated loom with stop the line capability almost 100 years ago. I write more about that in my first blog in a three-part series on building the quality in on the SmartBear blog.

It may seem old school, but every now and then I’ll start pristine Emacs and hack away on a piece of Java. I mainly do this for small stuff, since starting or setting up Eclipse takes a little bit too long for such minor projects. Even so, I don’t do this as often as I used to.

Why? I guess you know the answer: Nowadays, even the thought of not having instant feedback on syntactical and semantical correctness makes me shudder. It’s like coding in the dark. Incremental compilation is one of those great innovations that have increased the quality of our work.

Read the rest of the blog at SmartBear.

Size matters, why and how to measure your heap

Posted on by

I have had to deal with memory problems in Java applications a few times. A lot has been written about this already, but this time I ran into a slightly different issue that surprised some of my colleagues so I decided to write about it here. Contrary to popular belief, a big JVM heap size is not always better when it comes to performance.

The problem

I came to the customer site to help them with their performance problems of a fairly large J2EE-system Web Service/Hibernate/MySQL system. They had several customers running the system, but only the largest was experiencing problems. The application suddenly froze and stopped processing transactions. All sorts of hypotheses were discussed, but no one could really for sure say what the problem was. And there was little data to work on.

read more »

Code archeology 101: Custom Exception Hierarchies

Posted on by

After having worked with various legacy codebases one discovers certain recurring traits and patterns. The topic of today is the Custom Exception Hierarchy encountered in Java legacy code. This phenomenon is rather Java-specific because of that language’s checked exceptions.

So what is a Custom Exception Hierarchy? It’s an exception hierarchy, with some strangely named exception at its root, present throughout the entire codebase and used everywhere. The author(s) of such hierarchy obviously felt that exceptions like IllegalStateException or IllegalArgumentException, or the like weren’t sufficient for the sophisticated needs of their application, so they came up with a better suited hierarchy of checked exceptions.

read more »

Is your software architecture explicit?

Posted on by

You know, every system has a software architecture and a software design. Whether you think about your system’s architecture or not, it will have one.

Here is an example of two methods in a class I recently saw. It is not architecture, it is good old OOD, but it exemplifies what can happen if you do not think before you code.

protected String getSystemArg(final String key) {
  return parameters.get(ARG_PREFIX + key);

public Map<String, String> getSystemArgs() {
  final Map<String, String> map = new HashMap<String, String>();
  for (final Map.Entry<String, String> e : getParameterMap().entrySet()) {
    if (e.getKey().startsWith(ARG_PREFIX)) {
      final String newKey = e.getKey().substring(ARG_PREFIX.length());
      map.put(newKey, e.getValue());
  return map;

Both methods in the class handles the same parameter map. The first method returns a “SystemArg” for a specific key from the parameter map. The same parameter map that the second method in some obscure way gives you in total (but with keys without the ARG_PREFIX).
The first method is protected. The second is public. Which one would you have used if you have a key for which you want a “SystemArg”? Which one would you like to use?
This is an example of what you get if you do not think about your design. A public interface of a class that blatantly shows the inner workings, and a protected interface that is what should have been the public one in the first place.

To me, an explicit architecture is visible. All team members knows about it, i.e. it is well communicated. To make such an architecture you need to be aware of the decisions you make and why. This means that the team(s) need to have discussions, perhaps draw some interaction diagrams on a white board, maybe make a domain model and whatnot. Just do something. Anything is better than nothing.

White board area next to Sprint Backlog

White board area next to Sprint Backlog

Example of explicit architecture

Example of explicit architecture.

Agile does not prohibit you from doing design or architecture. It certainly does not prohibit you from using your brain. It only states that you shouldn’t do it all upfront, but rather evolve it over time, just as your requirements evolve. So please, think about your architecture and make it explicit. Because if you get an implicit architecture, you will be knee-deep in technical debt and then you will call me to come and fix it…

Analog Clock Revisited

Posted on by

Screenshot of the analog clockI have been playing around with JavaFX on and off since it came out and I got really inspired by Per’s blog post about the analog clock. So I decided to spend my time at the Crisp Hack Summit trying to improve Per’s design both in code and visually.

read more »

Using CloudBees for teaching XP practices

Posted on by and

We are doing a course called “Certified Scrum Developer”.  We are of course proud of being one of the few eligible by the Scrum Alliance to hold such a course. But what matters most to us is teaching some modern development practices. The certificate bit is more of a bonus.

Crisp had recently its fifth installment of a code camp, the “Crisp Hack Summit”. It is an occasion for everyone at Crisp to go bananas on some project of their liking. We took the chance to work on the technical platform for the CSD course.  We know from experience that you can loose a lot of valuable lecture time if  the technical environment decides to hassle. Murphy, will you be there?

read more »

Bootstrapping an agile project with continuous deployment using cloudbees

Posted on by

Starting from scratch, this video demos how to quickly get to a fully agile project setup with continuous deployment.

Everything is in the cloud – GIT repo, Jenkins, MongoDB, and the app server. The system deploys automatically with every successful commit.

The app itself is minimal, but does have a simple web interface and a database. The idea is that once you get a “walking skeleton” app like this running in the cloud with continuous deployment, you can get user feedback early and often, and evolve more quickly.

The video demonstrates:

  • iterative development with VERY fast feedback loop
  • a dash of TDD
  • continuous deployment via git & jenkins & cloudbees
  • using eclipse tightly integrated with maven, jetty, and git.
  • the basics of mongo DB
  • the basics of java servlet development (I’ve intentionally avoided using a 3rd party web framework, as this setup will work for any web framework).

On Unit Testing and Mockito

Posted on by

This is just a blog post to point to my presentation of the aforementioned subject. Or should I say, “prezi”, because there are no slides, just a big picture with a path through it. That’s is the way of Prezi presentations and as a first timer, I felt liberated. Slides are so dull!

The content of my presentation is aimed at those with some experience of unit testing that would like a dose of philosophy on testing styles. Classical or Mockist? State or Behavior? Also, if you are not that familiar with Mockito, take this prezi for a spin!

Here is the link to the prezi! That’s all for now.

read more »

Functional Java

Posted on by

I have just finished reading a neat little book about functional programming for Java developers by Dean Wampler. The book is only sixty pages long so it’s a really fast reading. This is a book for Java programmers and others working in the object oriented paradigm that haven’t read about or done any functional programming before. If that fits you then this book may be a good choice to read. Otherwise, I recommend that you seek more advanced and in-depth books in the subject instead. But this text will not be a review of the book. I will instead comment on the use of the functional structure and its paradigm in languages like Java that is not designed for it.

read more »

Mönster för flertrådade enhetstester

Posted on by

Detta är ett designmönster för hur man skriver ett enhetstest som utför samma test samtidigt i flera trådar.

Genom att utnyttja java.util.concurrent på ett smart sätt säkerställer man maximal samtidighet, vilken kan avslöja trådbuggar.

Kom ihåg: det går inte att bevisa att ett program är fritt från trådbuggar. Det handlar om att göra det sannolikt att det fungerar i en flertrådad miljö.


    public void testSomething() {

    public void testConcurrentAuthInfoResponse() throws InterruptedException {
        final int threads = 100;

        final CountDownLatch readyToStart = new CountDownLatch(threads);
        final CountDownLatch startingGun = new CountDownLatch(1);
        final CountDownLatch finishLine = new CountDownLatch(threads);
        final AtomicInteger failCount = new AtomicInteger();

        for (int i=0; i

Visserligen en hel del boilerplate, men det kan man faktorera ut till en Template á là Springs JdbcTemplate.

Some Gotchas for Java Developers Learning JavaFX

Posted on by

In an earlier post, I had attached slides from a presentation on JavaFX that contained some code examples. I discovered that at least one of them, the ball game, stopped working when I switched to JavaFX 1.3.

I would say it is a quite subtle difference.

What happened was that the onKeyPressed and onKeyReleased were not called. My immediate reaction was that it was due to some bug in JavaFX but yesterday I realized what had happened.

read more »

Technology stressed? Perhaps it is time to panic!

Posted on by

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?

Don’t let Java ruin your JavaFX

Posted on by

Me and Oscar is currently working on a small project, just to learn JavaFX.

We stumbled on some nasty crashes which we at first did not understand.

ArrayIndexOutOfBoundsException? Is there a bug in JavaFX?

It turned out to be a callback from Java. Let us see how we got there.

The application we are doing is based on Crisp’s famous planning poker cards. They are great but you need to be in the same room. So we thought, why not do an online version for those teams that are geographically disperse?


The table has room for you and 8 other players. As you see from the picture, there is also a text chat to the right. At the same time, a small bubble appears by the card of the player that wrote in the chat. The bubble fades away after a ten seconds, unless the player makes another comment within that time. In that case, the latter comment is added to the bubble and it was here our problems showed up.

The chat is using a standard protocol, XMPP, to talk to the server. We don’t have to provide our own server, any chat server that speaks XMPP will do, e.g. jabber.org. Of course, all players need to have an account there.

Here is a strength that JavaFX has as newcomer, you can use existing Java libraries.

We found Smack that talks XMPP and did a small test in Java to see that we had understood it.

Now, how do one provide a JavaFX class that receives callbacks from Java? Each time there is a message from the chat, Smack will call your PacketListener. That is an interface and JavaFX does not have interfaces. It turned out to be so straightforward, however. Just extend the PacketListener interface as if it had been a class.

Here is a code snippet:

So we override the function that gives us the packet. Now comes the crucial part, the callback is done on its own thread. JavaFX has a single thread model for everything in the GUI and that code is not thread safe.

In our case we wished to display a bubble if there was none, or add to an existing one.

You should not do that. You should wait in line for your turn. Or something nasty may happen.

Remember Swing’s invokeLater? Here we need to say FX.deferAction. But in JavaFX we can pass functions as arguments. So here goes that part of the code.

You may also note that we use the chat channel to send commands.

So if you remember the threads, it is safe to have a callback from Java to your JavaFX code.

Java 7 update från Alex Miller

Posted on by

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

Posted on by

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:

  1. Add comments to your code
  2. Do not complicate things
  3. Keep in Mind – "Less is more" is not always better
  4. No hard coding please
  5. Do not invent your own frameworks
  6. Say no to Print lines and String Concatenations
  7. Pay attention to the GUI
  8. Always Prepare Document Requirements
  9. Unit-test. Unit-test. Unit-test
  10. 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:

  1. 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!

  2. Do not complicate things

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

  3. 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.

  4. No hard coding please

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

  5. Do not invent your own frameworks

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

  6. Say no to Print lines and String Concatenations

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

  7. 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!

  8. 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.

  9. Unit-test. Unit-test. Unit-test

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

  10. 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

Posted on by

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?

Posted on by

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

Posted on by

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?

Posted on by

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

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

Posted on by

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

Posted on by

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

Posted on by

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.

Terracotta clustering of Scala Actors

Posted on by

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!

Ouch, Howard Lewis Ship dumpar Maven

Posted on by

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.

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

Posted on by

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":

  1. 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.
  2. 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.)
  3. 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.
  4. 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.
  5. 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.
  6. Det bör helst inte överge tidigare investeringar i redan existerande kod.
  7. 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.
  8. 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

Posted on by

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:

public class WidgetList
WidgetList getDiscounted() { /* ... */ }

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

Här är en annan goding:

public class WidgetList
String getAll() { /* ... */ }

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?