Tag Archives: Java

Bad Java, no cake for you! – Java 8 default methods versus Scala traits

Java 8 was released recently and one of the much heralded features is Default methods. Simply put, these allow you to inject functionality to classes via interfaces. This is a new feature in that prior to Java 8, Interfaces could only have method signatures and not have the implementation and only Abstract classes could have method implementations but that has now changed.

Here’s a simple example that prints out “In InterfaceOne”

In Scala, another JVM language, you can do something similar but more awesome with Scala’s traits (its version of interfaces) you can override similar implementations and have a version of multiple inheritance. This example prints out “In TraitTwo”

The secret that avoid that diamond of death is that whichever trait is declared last wins. If I’d swapped around the order that the traits were declared then it would have printed “In TraitOne”

What is even nicer in Scala is that you can declare your class with traits when you instantiate it. You don’t have to declare it at the compile time of the class. This means that you have a powerful way to extend functionality of classes but without the insanity of monkey patching. ThisThe below example also prints out “In TraitTwo” but the class does not extend any trait. This of course is Scala’s cake pattern where you can mix in the traits.

What is slightly disappointing with Java 8 is that you cannot mimic this behaviour. If you try to do this in Java 8, you get a nice compile time error telling us the class inherits unrelated defaults.

I wonder why they chose not to support this. The cake patterns seems like a feature that adds flexibility without being able to shoot yourself in the foot too much.

 

Are Exchanges Just Glorified Chat Applications?

I came across an interesting post here on why Betfair should fear whatsapp. Strange bedfellows for an article but the general thrust of the piece is that a chat application is similar to a financial exchange, in this case Betfair, and could theoretically disrupt its business model. I have to be honest and say it’s something I’ve never thought of.

If you read what’s said then you might think that this is so. The author goes into some detail about the similarities and given the depth of knowledge in some of the other posts on his site you might think that he’s got a point. He even says straight out that “A betting exchange is really just a chat application – in place of messages, you have bets; in place of chat groups, you have markets; and in place of the chat transcript, you have the order book“.

So that’s a fair comparison isn’t it?

Ummm, nope and here’s why. Continue reading

2012 Technical Goals

I hate making resolutions but I like making goals. That might seem slightly contradictory but consistency is the bugbear of small minds and all that. Here’s a list of my current technical goals:

  • Write an iPhone application – I even have a half decent idea of what this should do thanks to Abe’s angry ranting at lunchtime. Thanks Abe!
  • Write a Node.js application – I’m not a fan of event loops since they are implicitly single threaded and so single cored. While this is a good fit for simple scatter gather web applications, as soon as you have any sort of processing you are a bit fucked. That said, one of my mottos is “don’t knock it til you’ve tried it” and while I’ve knocked up the obligatory chat server, I need to have a better understanding of
  • Write a Scala/Play!/Akka application and host it on Heroku – this should be an easy one and I’m looking forward to it. Scala, Play! and Akka could be the new JVM stack of choice and Heroku certainly looks the polyglot cloud platform of choice.
  • Write a Clojure application and host it on Heroku – not so easy since I don’t grok LISP but the constant chatter about the REPL and the power of immutability has a certain attraction.
  • Write a book – since my previous post was about this it should not be a surprise.
  • Present at more conferences – I popped my speaking cherry in 2011 and really enjoyed it. Now to really get out there.
  • Get more involved in the London Java Community – the LJC is an awesome group and the more you put in the more you get out.
  • Put more stuff on Github and open source it.
  • Convince my current client that they should open source their code – my current client have some really sweet code and they are happy to open source it but they’ve never done it. I have to push for this to happen.
  • Be technically excellent – I have some really challenging work coming up. It’s going to be tough and demanding and I’m going to have to be at my best.

What ever your goals are, I hope you have an awesome 2012.

Talking at a Conference

The fear of public speaking regularly comes in at number 1 in a top 10 of people’s biggest fears. It’s generally agreed that the idea of standing up in front of a group of people to give a talk is terrifying so you won’t judge me too harshly when I say that I was lightly cacking my pants when I went to the London Java Community Open Conference last week since I planned to be up on stage to give my first ever talk.

Unlike normal conferences where you have a schedule of speakers in advance, in an Open Conference anyone can put their name down for a talk. I decided that is something is worth doing then it’s worth doing twice by entering two talks: one 30 mins talk detailing my current team’s work as we rebuild a high volume website in Java (peaks of 30,000 executions in a minute and 88,000 http requests per SECOND! – slides) and one lightning talk of 5 minutes only to compare threads and actors for concurrency (slides).

Supplied with enough coffee and pastries to gird my loins, I put my name in for both and went in for the main kickoff session from Martijn Verburg and Ben Evans. As soon as that had finished I darted out to look at the schedule and saw what every first time speaker wants to see- I was first up!

Joking aside, this is perfect since you don’t end up sitting waiting for your turn and I bolted to my meeting room and got set up as quickly as I could. That I could welcome everyone in made me feel in control but with less than 5 minutes to go I only had way fewer people that I had hoped. Let’s face it, as a first time speaker you want to steer between the Scylla and Charybdis of too few and too many attendees. There’s no way I want to give my talk to the entire conference but likewise, I’d feel a little foolish giving it to only a couple of people.

Thankfully, the last couple of minutes before the start time saw the room fill up and I gave my talk to a full room of about 25 people. It may have been a bit of a cheat but the majority of this talk was based on the one given by Tim Morrow at Velocity EU so not only did I know the topic well but I had seen it been given by an experienced (and good!) speaker already. As soon as I got passed the first slide any nervousness had evaporated and I was off and running. I’d practised it a few times so timing the talk was not hard and the presenter view on powerpoint rocks since it gives you both the running time and your progress through your deck of slides. I was a little nervous about question time but since this was a case study on my own work I was on pretty safe ground.

My second talk was after lunch which meant that I had to sweat through that and the 3 speakers before me. That and the fact that this one was going to be to the full Five minute talks are simultaneously easy and hard – your time is too short to get into too much detail so you can focus on the area in hand (i.e. the bits you know!) but you have to have a perversely good understanding to explain your topic in only 5 minutes since you only have time for salient points. I was way more nervous for my lightning talk but again the waiting was far worse than actually standing up there and talking. Again, the questions were the hard bit and someone asked a great question that I didn’t know the answer to – “will Akka support Java in the future?”. What was cool was that the best way to answer this was to join up to the Akka user mailing list (something I have been meaning to do but never have) and ask and it doesn’t get much better when the Tech Lead and the CTO of the company behind Akka answer (“Abso-friggin-lutely, wouldn’t want it any other way.” according to the Tech Lead).

So how did it feel to finally give a talk? I felt far more involved that I ever had before. Yes people come up and talk to you afterwards and you end up chatting with other speakers whether you like it or not (and you do!) but the effort you put into your talk means that you are naturally interested in what everyone else is talking about and whether it affects your topic. The whole subject of the conference seems far more related to your own interests. It might be because you are interested enough in that topic to want to give a talk on part of it but I think that giving something back in this fashion creates an emotional bond that dispels any sense of imposter syndrome and just lets you enjoy the conference more. You don’t have to find a justification for just being there and you also learn far more.

So if you are thinking about giving a talk, all I can say is get stuck in and give it a go.

Job Ads Are A Valid Indicator Of Programming Language Acceptance

I found an article from a mystery blogger here called Job Ads Do Not Reflect Programming Language Popularity that covered my post on Scala, Groovy, Clojure, Jython, JRuby and Java: Jobs by Language. It’s well written and pretty fair and I think that anyone who found the my original article interesting should go over there and read it. That said, there are a few points that I’d like to expand on if you will indulge me.

1) The job percentage of 3.5% for Java is across ALL jobs on indeed.com not just IT related ones (there are 2x as many Java jobs as there are listings for accountants 🙂 ) which makes the 3.5% value quite respectable.

2) The stats do seem to imply that Scala and Groovy have far more momentum than Clojure. I know some real Clojure fans but compared to the relevant Scala and Groovy user groups they seem to be a little more active. Also, both Scala and Groovy have killer weapon in the Akka and Grails frameworks. I don’t know if the same can be said for Clojure (Noir?) and would be happy to be proven wrong. I don’t think that the importance of having these weapons can be underestimated. It gives both languages great leverage in getting in the door of businesses and once they are in the door then I would expect more general usage to follow.

In the original article I showed the graph below and mentioned that it was likely that Scala would overtake Jython and that in fact, Scala’s growth rate had overtaken Groovy’s (although with a caveat that it was only a few data points and so could be a ‘flash in the pan’).

Now this is the same graph 6 weeks later…

It looks like I was right on both predictions (cue outrageous smugness!) but they both seemed reasonably obvious. The one thing I did not guess was the Groovy’s grow rate would have stalled like it has. I hope it’s only temporary.

The author goes on to give a very good time line of the development of a language but doesn’t mention that crossing the chasm is the hardest thing for any language and that’s where both Scala and Clojure are right now.

3) I completely agree with the average Java developer caring less for programming since it is currently the default language of the majority. By this fact you will find more close-to-the-mean programmers using it than any other language. Given the volume of jobs out there the stickiness of the jobs can’t be that different and because of this I think that job listings are a valid metric of the industry acceptance of a language. Even if they are only slightly indicative, you would have to show that jobs in other languages are 60x stickier to be on a par with Java or that Clojure jobs are 6x stickier than Scala jobs.

4) I hope that I never gave the impression that if you are a Java developer that you shouldn’t bother to learn new JVM languages. I completely agree with my mystery friend that knowing new languages makes you more employable. As someone deeply involved in the recruitment process at my current employer I can personally attest to this. I would go as far as to suggest that knowing more languages makes you a better programmer since it exposes you to more ways of doing the same thing. More tools in your toolbox gives you a better chance of picking the right one and using it correctly.

As for whether my final paragraph was too strong, I can only say that I call ’em as I see ’em. Yes I am a bigger fan of Scala and Groovy than I am of Clojure but please don’t take this as evidence that I am somehow against Clojure. Clojure is a beautiful language but it suffers from the fact that it lacks the aforementioned ‘weapon’ and is just so different from Java that companies will shy away from it worried about how long it will take them to spin up their entire workforce, not just their elite teams.

Maybe I can phrase it differently this time; it doesn’t matter whether you are a Java developer or not, the best thing you can do is to read “Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages” by Bruce Tate. Learning Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell will do great things for anyone’s understanding of programming languages.

 

Jetty 8 Maven Plugin

I love how easy it is to integrate Jetty into a Maven build but for some reason, all the examples use a 3 year old version of Jetty. Trying to find the latest version of an artefact can be a bit of a pain so here it is 🙂

    <build>
        <plugins>
            <plugin>
                <groupId>org.mortbay.jetty</groupId>
                <artifactId>jetty-maven-plugin</artifactId>
                <version>8.0.4.v20111024</version>
                <configuration>
                    <webApp>
                        <contextPath>/</contextPath>
                    </webApp>
                    <stopPort>9966</stopPort>
                    <stopKey>foo</stopKey>
                </configuration>
            </plugin>
        </plugins>
    </build>

Staying Sharp: Playing With New Technologies

My work has kicked into top gear in the last couple of weeks. I’ve had so many demands on my time that I have been unable to do any coding. Now I know that that is part and parcel of being a Tech Lead but the moment you step away from the code you start to lose the qualities that make you so useful to the business, i.e. being able to stick your nose into the codebase and shout “Yep, I know what this bit does.”

So I’ve been spending a few hours every night keeping my skills sharp on a project that a) has a direct impact on what I do everyday and b) is bloody good fun. How much fun I here you ask? So much that my wife forced me to sleep in the “huff” bed (the spare room – where you go when you are too angry or too drunk to sleep together) since I kept talking about what I was doing.

So what is it? Some multi-threaded mayhem of course!

Not really of course. I regard manual thread manipulation and the last refuge of fools and geniuses and I ain’t either. My current project is a web application which makes a large number of concurrent requests for each page request. We use various bits of the java.util.concurrent libs to do this. This works great but at scale can cause issues since each thread takes a few MB. Once you’ve spun up a couple of thousand of them, your machine has eaten itself. A solution to this would be to use Actors instead and since the excellent Akka framework can be used in Java and not just Scala I thought I would give it a go. At the same time, since it was a home project I thought I would use Git for version control.

I finished up the project today and it’s pretty cool. Akka’s syntax in Java is comparatively clunky to its syntax in Scala but I’ve seen far worse. Some perf testing on Monday should show what difference it makes and if it is good enough I might take it to the next LJC meeting.

Scala, Groovy, Clojure, Jython, JRuby and Java: Jobs by Language

In a previous post I pointed out that one of the more obvious recent changes in the Java landscape has been the meteoric rise in popularity of other languages for the JVM.  Some are old and some are new but JVM compatible versions of established languages with the likes of JRuby and Jython, Java-esque languages like Groovy and Scala and brand new languages like Clojure and Kotlin offer genuine options for those that appreciate the performance and reliability of the JVM but also want a different syntax.

In an ideal world all developers would be able to develop in the language of their choice. The reality is that as developers we are constrained by the suitability of the language, the tooling support and by what languages companies are actually using. Firstly, you choose the language appropriate to the domain – one that lets you do your job quickly and easily but with the appropriate level of support for your non-functional requirements like performance.  Secondly no one wants to be slogging through the coding process in a simple editor. Yes, I know that we could all use vim or emacs but being able to refactor large swathes of code easily and quickly (hello TDD!) kind of demands a modern IDE like IntelliJ or Eclipse. Thirdly, the reality of the situation is that very few of us are in the position to be able to dictate to our employers what language we should be using. Learning a language with rising popularity also means that you have a greater chance of being employed in the future (which is nice) but employers drive the acceptance of new languages.

The fact is that many companies boast about using the latest and greatest languages since it makes them more attractive to candidates. You can barely move for the blog posts and tweets of people raving about how their company has completely changed their development process with a new language but what is the real picture?

For a useful indication of industry acceptance we can go on the job trends on indeed.com. The grand daddy of language charts is Tiobe but it’s no use at this point since a) it does not provide sufficient information and b) is too easily gamed – yes Delphi dudes, we know what you did. Now before you complain, I know that using something like this is far from perfect and a long way from scientific but unless you fancy doing a longitudinal study going asking all the companies what they are using and believing their answers are real rather than marketing fluff, it’s probably good enough to be illustrative.

So what can this tell us about the how the industry sees the major language of the JVM: Java, Groovy, Scala, Clojure, Jython and JRuby*. What happens when we have a look at the percentage of all jobs that mention these languages

Umm, well… it’s pretty obvious that despite all the industry noises about other languages, Java is still massively dominant in the job marketplace with almost 3.5% of the jobs requiring Java knowledge. We all know that Java is an industry heavyweight but it is a bit of a surprise that in comparison the other languages are an indistinguishable line. Welded close to the 0 line, they would need some seriously exponential grow to start to threaten Java.

So what happens when you remove Java….

This is a lot more interesting. Firstly Jython was the first language other than Java that was really accepted on the JVM. Groovy started to pick up in 2007 and quickly became the first of the alternate languages, no doubt driven by Grails. Clojure and JRuby have never really garnered much support despite the recent rise in the last 18 months or so. I think the most interesting point is the recent increase in the acceptance of Scala. Currently third behind Jython, the gradient indicates that it will soon move into second. Comparing the grow rate of Scala and Groovy on a relative basis we see the following.

So we can see that Scala has finally crossed over Groovy’s growth rate. It’s completely reasonable to say that this could be temporary and that we should not read too much into this but there are a few data points there so it does not appear a flash in the pan.

So what can we say; while you’ll want to dust off the old Groovy text books and maybe have a look at some Scala tutorials, the best thing you can do is to keep your Java-fu in top notch order. As far as the industry is concerned Java is still the Daddy of the JVM languages and seems to being staying this way for some time.

* – I did originally include Kotlin and Gosu but since there were 0 jobs for Kotlin and only about 9 for Gosu they would only have been noise.

The First Class Languages of the JVM

The announcement of Kotlin, a JVM based language from JetBrains, drew quite a bit of attention. Firstly, when the makers of the best Java IDE in the world announce their own language you pay attention and secondly, it wasn’t that long ago that to the average developer the JVM meant Java and only Java and the rise of other languages on the JVM was some sort of bizzaro dream. While Jython (1997) and JRuby (2001) predate Groovy (2003-ish) it was the latter that really seemed to show everyone that something other than Java could be run on the JVM. The fact that Groovy is a super-set of the Java language meant that the barrier to adoption was very low and developers seemed to lap it up. This encouraged adoption but the push from the likes of SpringSource and the rise of Grails piggy-backing on Ruby on Rails’ success seemed to drive its acceptance. Even the fairly poor tooling support seemed to not be too much of a barrier as many companies started using it and benefiting from something other than Java.

Kotlin’s emergence does raise an interesting question;  from the developers perspective, what are the first class languages for the JVM right now and who will be in that list in 3-5 years time, and more importantly why?

Of all the languages that can run on the JVM, I would say that the the list of the premier league languages can be restricted to the following: Java (natch), JRuby, Jython, Clojure, Groovy and Scala (Kotlin is interesting but until Jetbrains write IntelliJ in it I won’t take it too seriously). Of these 6 languages it also interesting to note that only 2, Java and Scala, are statically typed and 3 are versions of a previous language: JRuby (Ruby somewhat obviously!), Jython (Python) and Clojure (Lisp dialect).

Scala has been seen as the language most likely to supplant Java but its complexity (especially the multiple different ways you can write and do the same thing) has held it back. It’s functional nature has also meant that many Java/OOP developers freeze in the headlights when Scala code switches to this mode. Scala is awesomely powerful and the likes of Twitter, Foursquare and GridGain use it in missions critical systems but it currently lacks that magic sauce that makes it accessible to mere mortal developers.

The same goes for Clojure. Lisp and its dialects has never really found a massive following in the commercial environment despite being held in high regard elsewhere. Even with the increasing interest in functional languages it still does not have the momentum required to be wildly successful but it is still early days for Clojure.

Ruby (1995) and Python (1991) are not new languages. Since there appear to be about 3.5 times as many jobs currently being advertised for Java than for Ruby and Python combined  it appears unlikely that even JVM friendly versions of them will be the next big thing. Don’t get me wrong, Jython and JRuby are great languages but they are hardly new kids on the block.

Groovy‘s similarity to Java makes it’s adoption very easy but its performance historically has not not great. I’m being polite since it’s actually sucked pretty hard.. Whether this is still an issue with the inclusion of JSR 292 in JDK 7(Supporting Dynamically Typed Languages on the Java Platform) remains to be seen but the dynamic typing does not tend to be as accepted as static typing in the enterprise context. I know this is a contentious point but Nuxeo moved from Python to Java and Twitter’s adoption of Scala indicate that context is important: if you have a large-scale performance orientated application, static typing is your friend and this is where Java is used heavily. Should you really like Groovy’s syntax and want static typing, Groovy++ offers what you need but again, does it offer enough to replace Java. I’d have to say no.

So what will be the language that retires Java? I have no idea and I don’t think that anybody else does either but I suspect that the language that finally does has not been written yet. It appears that the usage of Scala, Groovy, Clojure, Jython and JRuby will increase in the next few years but none of them seem to be the Java killer. The increasing adoption of languages with better type systems than Java seems assured for the the next few years but none of them seem to offer the combination of features to supplant Java.

If I had to back one of the runners, Scala appears to be the one with the most momentum as well as arguably the most power and functionality. The perception of complexity can be dealt with by education and training so it may well grow to be a contender to Java but given the learning curve, it is hard to see it ever replacing it. Who knows, it may be a language from an IDE company that finally sees Java developers cry “The King is dead, long live the King.”

Closure Syntax in Java 8

The expert group for Java 8 have announced the syntax for closures. Thankfully, they have chosen the sane route of choosing a similar syntax to Scala and C#. Quoting from http://mail.openjdk.java.net/pipermail/lambda-dev/2011-September/003936.html

The decision to choose this syntax was twofold:
– The syntax scores “pretty well” on most subjective measures (though
has cases where it looks bad, just like all the others do). In
particular, it does well with “small” lambdas that are used as method
arguments (a common case), and also does well with large
(multi-statement) lambdas.

– Despite extensive searching, there was no clear winner among the
alternatives (each form had some good aspects and some really not very
good aspects, and there was no form that was clearly better than the
others). So, we felt that it was better to choose something that has
already been shown to work well in the two languages that are most like
Java — C# and Scala — rather than to invent something new.

There is still some argument around fat versus thin arrow (surely a huge issue!) but for those of us that program in multiple languages it’s nice that they haven’t fallen for the “not invented here syndrome” and have chosen something that doesn’t require us to perform massive context switches when using something different.