Google+, Facebook, Twitter... is it going to be like the early days of IM?

I've been reading a few news articles about whether Google+ will manage to defeat Facebook or render Twitter obsolete. Here's a bit of speculation, but I wonder if it's going to be more like the early days of instant messaging (IM).

In those days, some of my colleagues were on ICQ or AOL but some were on Yahoo Messenger but some were on MSN but some had started to move to Skype etc. And that meant a lot of people had to have accounts with all of them because of course you can't control which of those systems the person you need to speak to likes to use. And tools like Kopete would spring up to help you deal with your many different messaging accounts.

It's pure speculation, but I think that's the direction I see the major networks going in. Already there are people who are Facebook friends whose Facebook status updates come from their Twitter app. Meanwhile many Twitter posts are there to point me to blog articles on blogs that I could also individually follow using RSS and Google Reader. And the rise of those social communities hasn't, for instance, stopped me from sometimes needing to use much older forms of community: forums, mailing lists, even (for a course I've been teaching) newsgroups.

So one more social network does not necessarily mean death to the rest. At the moment, I don't see Twitter and Facebook following Bebo and MySpace into relative insignificance. Instead to me it means another system I'll need to have an account on (well, if someone sends me an invite) because people I'll need or want to listen to use it.

(Edit: Thank you, I am now on Google+. Dominic, I can't seem to message you to say I'd already accepted an invitation just before yours came through; thanks for repeatedly inviting me, you are in my circles.)

AV referendum

Here are my (last minute) thoughts on Alternative Vote versus First-Past-the-Post, as someone who's lived and voted under both systems -- I've lived in both the UK and Australia.

First, if I was in the UK I would vote YES in the referendum.

The reason is that AV lets me vote for who I want to win, without worrying about whether I think they can win.  No more "Oh but in this constituency, its always been a two-horse race between X and Y so a voting for Z would be wasting your vote".

To knock out one myth, in theory it's not the extreme parties that benefit from AV -- it's the independents.  Extreme parties (pretty much by definition) don't have broad support, so they don't pick up many second preferences.  That should mean it's harder for an extreme candidate to get elected than a moderate candidate that everyone might put second.  But under First-Past-the-Post, a moderate well-liked independent candidate faces a daunting task persuading voters that he stands any chance at all of winning against the major parties, so under first-past-the-post many people who might want to vote for him won't because they think their vote will be wasted.  For me, that makes AV more democratic as the independent then stands or falls on the issues, not on gamesmanship about whether or not he can get enough other votes to be worth getting my vote too.

The side effect you do get in AV is the "How To Vote" card.  In Australia, parties don't just care that you put them first, they also care about who you might list second, third, fourth, and so on.  For example, Australian Labor (yes, it's spelt without the 'u') would much prefer you voted for the Greens second rather than the Nationals as a Green MP would be much more likely to support a Labor government in parliament.  So each party has activists stand outside the polls giving you pamphlets telling you not just who they'd like you to put first, but the numbers all the way down the list.  "How to Vote Labor", "How to Vote Liberal", "How to Vote Green", and other glossy pamphlets are thrust upon you on the way into to the polling station, in the hope of influencing your second and third preferences as well as your first.  And the parties do some deals with each other (especially with the minor parties) around where they put each other on the "How to vote" cards

But the thing is, as a voter, I can completely ignore those "How To Vote" cards.  So the side effect of AV is completely under control of the individual voter.  But the side effect of first-past-the-post ("Will enough other people vote for this guy that he's even in the race?  Am I wasting my vote here?") is bigger than any one voter and so there's nothing an individual voter can do about it.

In other words, you as an individual voter can stop the gamesmanship around AV, but you can't stop the gamesmanship around First-Past-the-Post.  To me, that again makes AV more democratic.

Unfortunate juxtaposition...

For some reason, the front page of the online Telegraph decided to run a pictorial on criminals' hairstyles today. Check out who looks like they're in the third row...

I mean, I know the Telegraph might not like Obama or Jobs, but what did the labrador do?

I guess the question is did they accidentally put it that bit too close to the images of their video items, or did someone slip a prank past the editor?

Humour: Children's belief in Santa is scientific

There's a famous cliché that gets bandied around if anyone has a hunch they can't quite prove: "Well, you might as well believe in Santa Claus". But here's the shocking flip side that for some reason we all seem to forget: When children believe in Santa, they are actually following the scientific process pretty well.

What? Surely that's ridiculous? Well, this is a humorous anecdote, but think about it for a second:

• Every year, they conduct a falsifiable objective experiment: they put out an empty sock, a glass of milk (or something stronger), and a cookie. And every year they get a positive result.
• They conduct peer review, asking each other the results of their experiments ("Did you get anything from Santa?") and all their fellow experimenters are also getting positive results.
• They even validate their experiment against the reports of esteemed experts who have conducted experiments many times in the past (their parents, teachers, and other grown-ups).
• And these days many of them have even set up cameras, and then seen video evidence of Santa consuming the cookies and milk that they put out.
  

Without fail, the experiment has always been a resounding success in every independent trial - far better than you can say, frankly, for a lot of real academic published experiments!

And of course the only reason they get the wrong result is because this time there really is a grand world-wide ongoing conspiracy to interfere with their experiments and falsify their results, and everyone is in on it! Forged videos and secret disguises! Evidence tampering, as Dad wolfs down that cooke! Deception by respected senior scientists (parents) they thought they could trust on a global scale!

Maybe there's a good cautionary tale for budding scientists in this. One seemingly sound but wrong assumption ("Surely not everyone I trust would lie to me about this?") can sink your whole experiment and leave you with an embarrassingly wrong result.

Apple's Java runtime "deprecated": less news than we might think?

Web news outlets have picked up on a comment in the release notes for the latest Apple Java update saying that Apple's version of Java is now deprecated and will receive less frequent updates. The new Mac App Store doesn't permit Java applications, so some, including The Register, have concluded that Apple is trying to kill Java on the Mac.

This time, I think they are seeing conspiracy theories unnecessarily. (For all I know, Apple might well want to kill Java, but this change makes sense even if they don't.)

When The Register first published their story, the author conflated "Java" with "Swing". The original version of the story, when trying to describe the few desktop apps that require Java, linked to a list of apps that use the Swing toolkit. And so, for instance, didn't include significant applications like Adobe's Flash Builder 4, which uses SWT not Swing. (The Reg has edited the story since then.)

Why does that matter? Well, at JavaOne Oracle trumpeted JavaFX not Swing as the way of the future for Java user interfaces. Oracle's JavaFX roadmap promises a Java plug-in that runs JavaFX without even starting the old abstract windowing toolkit (or, consequently, Swing). But the most visible part of Apple's investment in their own Java runtime has been making Swing look nice and work well on Apple desktops. So it sounds like Oracle effectively deprecated a lot of Apple's work for them!

Just under where Apple's release notes say "Java Deprecation", it immediately headlines "Third Party JVM Support" (effectively, making it easier to put Oracle's Java runtime on the Mac instead of Apple's.)

Meanwhile, the SWT toolkit that Eclipse and Adobe Flash Builder 4 use already the Mac's "Cocoa" bindings even when not using Apple's Java runtime. So those guys, including a lot of Java developers who use Eclipse, probably won't even notice a bump -- their interfaces should look identical on Oracle's runtime or on Apple's.

All in all, it seems as though deprecating the Apple Java runtime is an attempt to move Mac users to the Oracle Java runtime, not actually a nefarious "kill Java" machination after all.

Edit: The thing I'm trying to speculate, without overstepping the mark (it is just speculation), is that I reckon Oracle might have wanted this change to happen. Oracle's recently announced JavaFX roadmap promises a new browser plug-in. The browser plug-in for Java is normally part of the JRE. That suggests to me that Oracle would already have been thinking about whether they needed to take over providing the Mac JRE in order to deliver on their roadmap fast enough.

That could still be very worrying news for Swing/AWT on Mac, though.

Another JavaFX mistake: LoggerFactory.getLogger(this.getClass())

Every now and then I come across a mistake in our code (either mine or someone else's on the team) that demonstrates something about the JavaFX compiler -- a behaviour that breaks a hidden assumption that programmers sometimes have. Here's another one:



That code's got a potential mistake in it -- if you instantiate a subclass of AlignedContainer, the logger's name won't be AlignedContainer, but the name of the subclass. In JavaFX, the compiler generates subclasses for object literals, and you'll find that many of your loggers are named after generated classes.

So, in this particular case the logger ended up being

au.com.nicta.cose.comlex.fx.TimelineGui$1AlignedContainer$ObjLit$17

Which is a more awkward to turn on or off individually using log4j.properties (notice that one of the generated parts of the name, "TimelineGui$1", comes before "AlignedContainer"). Why is this the case? Well, the AlignedContainer was instantiated using an object literal:



The JavaFX compiler neatly generates an inner class extending AlignedContainer to implement this object literal:



So then it makes sense that this.getClass() does not return the AlignedContainer class but this anonymous inner class.

JavaFX Script isn't in JavaFX 2.0 - what's the practical impact for working with JavaFX now?

from my JavaOne talk.

At JavaOne, it was announced that JavaFX 2.0 won't support JavaFX Script. (Or at least, Oracle won't be updating the JavaFX Script compiler for JavaFX 2.0.) Although Oracle had kindly given partners and speakers a little advanced warning of this, I met quite a few people at JavaOne who were taken by surprise. And at face value, the situation today is a little odd:

• JavaFX 1.3.1 requires you to write in JavaFX Script
• JavaFX 2.0 won't let you write in JavaFX Script
• (and 2.0 isn't out until next year)

And many people find themselves in a dilemma: Does that mean all code for 1.3.1 has to be thrown away? What do you do until 2.0 is available if you can't just "wait a year" -- 2.0 code can't be written yet but 1.3.1 code would be wasted?

After rejigging my talk a little, I inserted a few slides on what I think the practical impact on our project is in the short term. After all, my team has a JavaFX 1.3.1 client. How has this announcement affected us?

Well, the first thing to say is that even today a lot of a JavaFX client can be written in Java. I ran some rough line counts on our JavaFX client -- the client I demo'ed at JavaOne -- and it came up as:

• 27% JavaFX Script
• 73% plain ol' Java

So the impact for us is a bit smaller than it appears. Part of that is because I was very cautious about committing the client to JavaFX. JavaFX 1.2, which we had to cope with until April 2010, had some very awkward bugs in it -- and there seemed to be a lot of risk with the Oracle buy-out and JavaFX gaining little market-share. So I kept as much of our code as possible in Java, ready to jump ship from JavaFX if we needed to. The libraries, model, data handling, and most of the guts of our code aren't written in JavaFX Script but just in Java. And it seems that's just as well. I realise other projects might not be in that situation though.

So this seems to be rule 1 for working with JavaFX at the moment:

If a class doesn't have to be written in JavaFX Script, write it in Java, Scala, Groovy or some other JVM language. Save yourself the effort of converting it later.

Various talks at JavaOne described possibilites for working in a JavaFX-Script-like way in JavaFX 2.0:

• Stephen Chin is keen to get an open source project going to update the JavaFX Script compiler so it can target 2.0
• Jonathan Giles and Stephen Chin showed how code in Scala, Groovy, or Clojure can look very similar indeed to JavaFX Script

In my view, it's too early to assess whether it will be easy to convert non-trivial JavaFX Script code to Scala or another JVM language. The 2.0 libraries are still being written, and nobody has much experience converting non-trivial apps yet -- even some of Oracle's demos in Richard Bair's JavaFX 2.0 talk were still written in JavaFX Script code; they hadn't been converted yet. It should be straightforward -- the 2.0 libraries are supposed to contain all the functionality of the existing JavaFX, so it should just be a matter of converting syntax, not redesigning your client. But let's wait and see on that.

It's also to early to assess whether the open source project to update the JavaFX Script compiler will be successful or not. Again, it should be. The JavaFX Script compiler always compiled to Java, and under 2.0 it'll have some libraries to target that will be a very close mapping to its language features.

So what can you do now?

• JavaFX 1.3.1 is a production release. And it works pretty well. (Unlike, say, 1.2!) So in the short term, targeting an app at 1.3.1 isn't so bad.
• JavaFX Script is still very fast for prototyping. Many of our visualisations were written in hours, not days. If you are doing prototyping or scientific experimentation where the results and the design decisions are more valuable than the code, JavaFX Script is still a pretty good choice.
• If you do keep most of your model code in Java, then the JavaFX Script code you write will usually be fairly simple. That means it's going to be less complicated to convert to another language if you decide to.

For my project, in fact, JavaFX Script not being supported in 2.0 makes very little difference. Government-funded research projects get fixed funding periods, and our current funding round finishes before 2.0 will be released. So we couldn't target 2.0 anyway. (If our hospital partners' experiments are successful, and more funding is won to take it further, that'd come with more development funding to deal with productisation issues -- including upgrading from 1.3.1 to 2.0. We'll make that as easy as possible to do, but we don't have to pencil it into the calendar yet.)