Thomas Hawtin's Weblog

Mea culpa. The dependency was mentioned in a JavaONE keynote this year. So why does creating a temporary file require SHA-1? (File makes use of lazy class loading in such a way that SHA-1 is not loaded for other uses of File.)

Well, there's a long history of guessable temporary file names being used as part of security attacks going back before Java. Two or more low risks combine to allow a useful exploit. See Chapter 4 of "Hacking: The Next Generation" for a discussion of what Microsoft calls blended threats. In fact Java vulnerabilities often result from combining multiple pieces across the JRE. I believe my record is six pieces of obscure information for one attack, rising to eight after the first attempt to fix it.

Veracode discovered this particular problem in the JRE only shortly after the relevant SSR had been pushed. I call that a success. Actually, even if it had been discovered externally and reported responsibly, I would very much call that a (non-technical) success. Of course, it could also have been found by exploits in the wild.

So, the problem is guessable temporary file names and the (short-term) fix is to use SecureRandom for creating each name. SecureRandom uses SHA-1 to generate a stream of random bits. SHA-1 is implementable in a small amount of code. However, in general you still want to be able to use hardware acceleration (although probably not necessary for file names), which means selecting and creating an implementation. Also needed is a source for the seed, and a back up method if the OS method fails. Add a plug-in architecture, and we get a lot of classes loaded at start up time just to create a temporary file.

In today's world, cryptography is in a practical sense more fundamental than local file systems. I expect the Javacard that got me onto the tube on Friday to be secure and keep my £13 safe (and however much I have on my other cards). I don't expect it to create temporary files in order to do so.

But why are we creating a temporary file? Generally it's so we can use ZipFile/JarFile which only work on local files, but we want to run a jar from the web. As well as the security risks, extra dependencies and complication of the code, this also causes extra disc activity at precisely the point we don't want it. A better approach is to streak the data into memory - secure, less dependencies, less complication and less disc access. Temporary files are so 1970s.

The other weekend saw the first ACCU Security day at Bletchley Park, subtitle security yesterday, today and tomorrow. As well as the three lectures, there was also an opportunity for a brief tour around Bletchley Park and The National Museum of Computing, including the replica Colossus.

How the Germans gave away their "unbreakable" codes. Tony Sale. Tony Sale led the team that build the replica Colossus, the electronic machine used to crack Lorenz ciphers from intercepted high-level communications in WWII. The last Colossus was dismantled at GCHQ in 1961, with supposedly all plans and pictures destroyed. The lecture went through example of how operational mistakes made by the Germans made transmissions vulnerable, and how the British (notably building on pre-war Polish work) cracked codes. I'm now a lot less confused about all the bits and pieces, I think.

The Coolest VOIP Protocol - Ever! Phil Zimmermann. Zimmermann was made famous by PGP. He claims a large part of its success over better backed rivals was the lack of a Public Key Infrastructure (PKI). I would point out still how little mail uses encryption, and the PKI-based signing could help fight against spam. We are also in a world with better experience of rolling out PKI. ZRTP is a PKI-less encrypted VOIP protocol, with a published spec and a disclosed source.

This time around the aim isn't so much just political. There's fraud out on the intertubes. Worse than that, criminals can wire-tap VOIP remotely. Difficult to do with private-infrastructure POTS. With the open interwebs, criminals in, say, Russia and China can be very nasty. Problems of intimidation in Russian journalism (quite a number of journalists have been murdered) and of the justice system were mentioned. With credit card numbers changing hands for about 10p due to dismal corporate security, it is probably more personal stuff we should worry about with VOIP.s

An interesting feature of ZRTP is a short fingerprint that you are supposed to confirm vocally. This is to prevent man-in-the-middle attacks. Without PKI you don't really know there isn't a MitM, the fingerprint allows you to confirm that you have a single session from end to end. If you have multiple calls, each fingerprint depends on the previous, so if you check fingerprints on later calls you know that earlier calls were also MitM-free. A MitM would have to try hard to impersonate the end caller to switch vocal fingerprint exchange in real time.

But if you run random .exes, ActiveX controls, AIR applications, etc., on the machine you use for VOIP (or web) you have much bigger problems anyway.

Cracking the Cipher Challenge. Simon Singh and his Enigma machine. Simon Singh discussed some of the ten codes in the £10,000 competition at the back of his book. Nice to see an actual Enigma in use. Interesting to see an attempt to reset the wheels two backwards failed because the middle wheel also moved one. An operational mistake was made creating the 3DES competition code - the message was actually encrypted in crackable single DES. I guess that's mistakes by the Singh and the Germans covered. Phil mentioned some manufacturers of ZRTP products initially failed to provide unguessable seeds, despite claiming that they absolutely would do. I have been known to make a mistake using GnuPGP, although that just made me look stupid.

I took a day off to go to the Stack Overflow DevDay in London. When further dates were announced, I thought it'd be fun to go revisit Amsterdam as well. Stack Overflow is full of pretty basic questions, with anything remotely interesting considered off topic. The presentations were dominated by live coding. I find that as much fun as watching play games. Give the keyboard to me! I am not interested. *yawn* Can't we have someone talking about something to make us think? Given the interdenominational nature of the audience, this would also increase relevance.

Opening Keynote. Joel Spolsky. Entertaining look at usability and usefulness. How programmers punt decisions, particularly security-related decisions, to users and don't see things for the user perspective. Nice to note how Apple is removing OK buttons (as is GNOME, and RISC OS was there about twenty years ago). Also (now that he has a bloated product?) about how more features are more better. Specifically good features (which is unfortunate).

Later on Joel did a FogBugz sales pitch, which I could do without. Product seemed to have a somewhat idealised approach to reality, and also an awful lot of OK buttons.

Python. In London, Michael Sparks went through Peter Norvig's spelling corrector. The example is far too cute. Not a task similar to the massive bulk of programming. The set comprehension looks like an anomalous piece of syntax. My brief introduction to Miranda helped understanding it, and not just zone out.

Simon Willison, in Amsterdam, showed neat use of the Python REPL helping him munge data for the Grauniad lefty newspaper (who wants facts with their cornflakes, anyway?). Scala has a REPL. What's up with Java?

Objective C was knew to me. Phil Nash's London presentation on iPhone development did indicate why it is called Objectionable C. Hopeless.

Pekka Kosonen (London) and Eero Bragge (Amsterdam) on Qt. Application development in C++? Get real. Old school GUI builder which didn't really work with the inaccuracies of a trackpad.

Food and drinks organisation at the London event was hopeless - huge queues. Fortunately it was easy enough to nip over across the road a get something. Amsterdam was much better, although I wasn't going to trust their milk. The downside of the catering was the noise during presentations. Very distracting even down near the front. Also distracting was the ultra high density seating. At least with RyanAir you know you can't run away.

As ever, I am a negative kind of guy. For little over $100 (or $150), I would go again next year.

Yesterday evening I went to see Derek & Clive[1] live on Programming Language Vulnerabilities at the West Oxford Community Center (organised by ACCU Oxford). One slide had a point relevant to the recent Project Coin discussions. C^♭ (a difficult to google verifiable subset of MISRA C) outlaws using the value of an assignment - assignment is always a statement and never an expression. Conversely, Java copies the unsafe design of commodious C.

One part of a Project Coin syntactical sugar feature is to enable replacement of verbose code of the form map.put(key, value) with map[key] = value. Much nicer. What could possibly go wrong?

Specified as a drop in replacement, we could replace every call to put with the new syntax. It has been pointed out that a = b[c] = d; would now not necessarily assign 'd' to 'a' (although for arrays it always did had fun with primitive conversions and from 1.5 boxing/unboxing). If b is a map, then that would be the equivalent of a = b.put(c, d);. Map.put returns the previous value. If map[key] = value were to return value (with conversion and box mangling) then naively updating code that use put's return value would introduce runtime errors not discovered by the compiler.

As usual, when there are two possible interpretations of compilable source, IMO it should not be the compiler that makes up our mind which we want. There are already too many unambiguous ambiguities in Java. The safe option is to treat it like a statement (actually to be an expression of type void due to grammatical restrictions).

Links:

• ACCU Oxford
• Plenty of discussion on the Project Coin mailing list

[1] Derek Jones & Clive Pygott

If you've googled a programming question this year, you'll probably know about Stack Overflow. Otherwise stackoverflow.com/about and stackoverflow.com/faq. Nice, one might even say sensible, URLs. But let's not talk about what works; let's talk about what doesn't work.

To me the most disappointing fail is with the wiki aspect. Sure capitalisation, formatting and spelling get fixed. This at least makes lazy questions appear presentable, even if no one can work out what was actually meant. What hasn't formed is a set of common questions with great explanations. It's just a shed load of badly asked questions with half a dozen times more haphazard answers. Perhaps there's room for another site to pick up the best of the cc-wiki licensed data, tidy and present usefully.

The manner in which questions are answered is highly dysfunctional. You need o get right in there with an answer at the top. A few minutes later and the action has moved elsewhere, and the top spots have gone. For best affect just write any old rubbish. Then re-edit (do this quickly and it doesn't cause a revision to be noted). You can then expand and copy other answers. Putting a bit of code in will get you many more votes, no matter how pointless the actual code is. Wouldn't it be better for the questioner to write their own code? Given the majority of the question, it's unlikely the original questioner is ever going to be able to think for themselves, even if they do get to grips with google. You cannot become adequately skilled by "page faulting" all the information needed for a programmer.

As previously mentioned, pointless code means points. Getting in quickly at the head of the list also helps greatly. Really very basic questions and their answers tend to get marked higher, although be careful with that. It appears that offering a bonus will actually get questions marked down. Popularity amongst the skewed population of stackoverflow is highly important - minority subjects wont attract votes. Using experience to guess at the real problem that isn't in the question, although rewarding, isn't rewarding in rep. Most important, being popular does make it right. There's plenty of people using singletons, that doesn't make them competent.

What does work really well: OpenID. Tired on every little outfit requiring you to give them your password (or store them in some book somewhere)? Given that the default model is one password for them all, there really should be legal sanction against sites that request, cause to be transfered or store passwords or sensitive information in an unencrypted or otherwise unsuitable manner. There is certainly no need for companies that I have purchased a single item from or forum sites to require passwords.

Anyway, I'd just like to say I've got a gold Java badge (#4)!, and see you at the London Stack Overflow DevDay.

I went a long to see Jeff Sutherland (co-inventor of Scrum and certified ScrumMaster) pitch Scrum and also see a great view over St Paul's and across South London. Quite probably, you and the majority of the audience are already sold on some form of agile development. (So why does software development in practice still suck so hard?)

The really notable thing for me in this presentation were the figures. Both the size and the consistency were stunning. We know that metrics are all over the place, so do these developers never take a toilet break? One particular graph had an incredibly level line. Jeff then went on to explain the bumps in it! With evidence this suspicious, how is one to trust anything else said? Of course the results "for publication" are cherrypicked, but this appears to be a situation I have often seen in the past: white fiddles, typically by managers.

You can't say anything will increase productivity by ten times - that would be a silver bullet. Over the last decade or so I have read and heard so many things that can increase productivity by five - only a half-silvered bullet. And apparently it is okay to have two of these, giving super-silver bullet hyperproductivity. Stick that in your pipe, Brooks!

If an application is running gratuitously slowly, there is a reasonable probability that the code causing the problem will be on a stack at any given instant. Stacks can be obtained with ctrl-\ (ctrl-break under Windows) or jstack. Better jconsole or visualvm will allow you to concentrate on a specific thread rather than wading through lots of waiting threads.

When you have the application running slow, take a few samples. Hopefully you can spot the issue. Whilst it wont always work, it has worked for me a number of times. The other week Netbeans did it's usual thing, and used CPU continuously but didn't quite die as such. hit it with jconsole (visualvm wouldn't pick up the process). It appeared to be doing a huge amount of disc access, but it was CPU bound and the disc light was off. So, probably reading the same files/directories over and over. Looking at the code involved the problem was obvious - a WeakHashMap with a transient key used as a cache. If you create a new object and only have a WeakReference to it, then that reference can be cleared immediately.

In real life the object has to wait for the garbage collector to notice it. Well, this used to be true. These days, after warming up the code sufficiently - perhaps several hours IDE usage - along comes HotSpot. I am guessing that an escape analysis operation has been implemented that allows detecting this situation and immediately passing the reference object over to the reference handler (this is more useful for finalisers which share some implementation). Using a SoftReference would be more appropriate for a cache (pity the current collections framework does not provide goodsupport for caches).

So do not use WeakHashMap/WeakReference to implement cache. It might work most of the time, but might fail unexpectedly in production.

See also:

• NamingFactory uses WeakHashMap for cache instead of SoftReferences

It's that time of year when I make my annual trip to near Oxford for the ACCU Conference. This time under my own wallet and on my own time. It's the best conference I've been to, so despite being more expensive than Devoxx, well worth it. (My top tip for Oxford: Instead of flying to Heathrow which is technically closer but hopeless unless you are going into the middle of London, fly to Birmingham and take the regular but over-priced train directly from the airport into Oxford.)

I was pleasantly surprised with the amount of Java about. You don't even have to say Java these days because it is the assumed lingua franca. That at a (formerly?) rabid C++ conference. Progress.

As ever, I have a critical mannerism. If I don't have something to say it's probably because the subject is tedious or perfect. Don't you find perfect things tedious? Thanks to every single presenter whose session I went to and those that organised.

So that I don't start off by laying into sessions:

The location is not the dreaming spires of Oxford. The location is the prefabrication of near-Oxford roundabouts. I had booked a room in the conference hotel to be in the action, despite despising the hotel and everything it stands for. Unfortunately it was overbooked. As the hotel staff liked to point out repeatedly it was not the hotel staff's fault. So I had been booked across a roundabout and up a dual carriage way (at least life-threatening situations are good for meeting people) into a hotel that also priced itself twice as much as I usually pay for a four star bed (even for the actually nice hotel in Venice the other week).

I spent much of the conference swearing at the Vodafone 3G software with its software craftsmanship issues. UI like it was written by a mid-90s VB programmer. Massively unreliable. Had to keep rebooting the machine. UX not helped by Vista. I think I shall try out 3, but I'm not convinced the experience will be any better although it will be more expensive.

Mind fade means I didn't take pencil and paper notes. Writing up during the conference takes too much time and detracts from attending (I should be in bed already).

Keynotes:

(Robert Martin) The Birth Of Software Craftsmanship Apparently the theme of the whole conference, or at least the battle of good vs bad craftsmanship. The way I see it, he underestimated where we were and overestimate where we are. Also, his methods are two small to be coherent.

(Linda Rising) The Benefits of Abstraction in Patterns Patterns are about abstracting out a common solution. With abstraction you can go over the top and lose too much information and understandability. The Do the Right Thing pattern is put forward as the abstraction of all [good] patterns. Do the Wrong Thing is probably a more widespread [bad/"anti"] pattern.

(Nicolai Josuttis) Welcome Crappy Code--The Death Of Code Quality A black, distopian look at trends in software craftsmanship. We should resign ourselves to the undeniable fact that most programmers will continue to suck. Instead of getting them to write good code in the first place, teams of elite janitors should tidy up code of the cack-handed masses. Where do you suppose efficiencies will be made straight away in that model?

(Susan Greenfield) Geeks, Nerds and Other Prejudices In which she explains that girls have an image of science as being full of sartorially-challenged, middle-aged, balding men to an audience of sartorially-challenged, balding men.

(Allan Kelly) Considerations for Successful Management Not too much for the morning after the Friday night. Money isn't a primary motivating factor to programmer [craftsmen]. Agreed. Apparently those attending the conference aren't likely to suddenly be out of a job. Those attendees currently out of a job presumably disagreed.

Sessions:

(Roger Orr) 'Refactoring without ropes' - changing programs in the real world The leading apostrophe character in the session title gained the abstract first place in the lexically-challenged conference programme. I don't know quite how the rest of the order was decided (but JDK7s upcoming sort should be able to sort it out quickly!!). Usual stuff about the practicalities of making mostly non-functional changes in the real world from the real world practical presenter. There was a bit of discussion about what constitutes non-functional in different situations, which I guess leads into a more general problem with compatibilities and bothering to specify anything useful.

(Alan Lenton) Holistic Security With the name "holistic" you might guess the lack of the specific. IMO you need to reduce to the specific practices even at a bridging level.

(Hubert Matthews) Modelling archetypes At the start of this session I had some skepticism. The core of the approach is to divide a domain's classes into four colour-coded categories (roughly - no paper remember): descriptive (blue), long-lived entities (green), roles (yellow) and events (red/pink). After Coad & Mayfield's Java Design book (I despised), I haven't looked at the Coad colouring-in book. However, Huber was very persuasive. It does look like it gives a shortcut to jump up to the abstract, grab the known issue and fall back down to the specific. I didn't like some of the discussion about implementing roles though.

(Kirk Pepperdine) Concurrency and Performance Reloaded Including the much anticipated debut of Kirk's striped (mostly) fifo queue. A year ago I though that the standard java.util.concurrent queue was striped, but apparently not. Nice approach to handling resizes. I do wonder if there is much of a market for an uber-contended queue. I guess Kirk knows.

There was a note that many collections methods don't make much sense in a concurrent situation. Indeed, the extra methods in ConcurrentMap make sense in Map, but what does size mean if before you can use it the size changes. Concurrent collections should make sense when use from a single thread. But what's the point. Shouldn't concurrent collections have interfaces all of their own?

Most of the audience appeared to be C++-heads, but perhaps with a more sophisticated "world" view than some other die hards.

(Didier Verna) Revisiting The Visitor: The 'Just Do It' Pattern Investigating Peter Norvig's claim that 16 out of the 23 [if you include the bad/"anti"] GoF patterns are trivial or vanish in Lisp. Most of the session was watching the presenter type code. Gah. Anyway, it seem in the case of Lisp that ditching encapsulation and making unwarranted assumptions does give you plenty of rope. You could presumably come up with something similar with reflection in Java if you were suitably evil.

(Kevlin Henney, Allan Kelly +5) The Pattern Buffet Seven presenters and seven patterns that you might not be familiar with but perhaps you should be. Pick of the bunch was Kevlin(!) and Aggregate Object (a.k.a. Whole Part). A bit on the abstract side, but nice to be able to put a finger on it.

(Bernhard Merkle) Stop the Software Architecture Erosion Got the bum deal from the schedule. Despite having the ar*********e word in the title and doing something that even from a refactoring point of view doesn't make any difference, was strangely compelling. IMO, a class in the wrong package (or collection of packages) is in some sense bad but not a problem worth sweeting over. Nor are packages decomposed along misguided lines the end of the world.

Some of my examples: javax.swing is codependent with javax.print. SerivceUIFactory is confused and should actually be in javax.swing or somewhere else. A common theme is common classes and root classes to fight for the top level class, such as System in java.lang alongside String. Some dependencies are just conveniences waiting for more comprehensive APIs for a single case, for instance java.awt dependence upon javax.swing. Other dependencies appear to be fine from a dependency diagram perspective but are problematic, for instance the Sun JDK Rhino adaption's dependence on sun.*. Even within the JDK some of these dependencies are fixed with copy and paste.

It's the classes that are important. A number of case studies were shown including JDK5 (it looked pretty!) and findbugs. We, of course, know about the modularisation efforts in JDK7 and Harmony, but you aren't going to change the public APIs (even though it is vital to do so). Even changing private APIs is asking to get flamed. FindBugs has more architectural issues than dependence - for instance confusion in the gui over EDT and non-EDT code.

This presentation wins my nomination for best pictures of the conference, although I had seen a couple before.

Workshopy things:

Workshops are not my home environment, but that is a reflection more on me than workshops. Something that I need to work on, preferably with the aid of dried snake pills.

(Mike Hill, Steve Freeman) Programming without getters An instructive "Coding Dojo" that wasn't instructive in the quite way it was intended to be. So despite, on the face of it, being a complete an utter failure, it was for me one of the best sessions of the conference. I hope Mike and Steve aren't put off and that they found it an opportunity to learn, though perhaps not about getters.

I think most of the people there took it as read to use behaving objects in favour of dumb structs. The venue has an odd idea about the optimal idea as to the height of projection screen, that seems to forget that there might be more than one row in the audience. That or most conference have vacuous PowerPoint that is only important to the speaker - I couldn't say which. Kirk Pepperdine and Uncle Bob made a foray into hardware.

It would appear that having Kirk in the audience seems to help make a session more memorable. He had a simple request that the class User become Shopper. Pointless? Perhaps, but something-that-uses is not much better than MyClass. Someone who is performing a role to shop is what we want. Amongst Eclipse's many features is class name refactor. Unfortunately Eclipse scores a big fat zero for usability. I guess a quarter of an hour or so of a five minute pairing was used to sort that cock-up out. More importantly the structure of the session was destroyed, due to the march of Ides.

There appeared to be two philosophies about how to refactor, and I wonder how many noticed the other side. They majority went for a bottom-up approach of incremental obvious changes. Kirk was, under my interpretation, going for a top-down approach. Slightly worryingly he seemed to go for a synthetic approach rather than mutating what was there.

We ended up with as many getter and setters as we started, and a few more lines of code. At least we had a positive kloc/hr! In fact if we had fiddled with the Hibernate mapping to make the sensible we could have cut much of the sourcerer's apprentice mess, but that would be falling into a cheat. Mostly what we learnt was that programming by committee is stressful.

(Peter Sommerlad, Kevlin Henney, Giovanni Asproni) Patterns of Simplicity This was the only session that I attended that was scheduled in the main hall. In fact it took place in one of the small rooms - spaceboxing they called it. Like most people I wasn't near a table. And I stayed pushed against the back wall. It seemed not sufficiently orientated and ignored the simple (or replaced it with trivial).

(Keith Braithwaite) Patterns for Distributed agile Developement Being the only Sun Java SE "developer" as such in the UK, and someone who has to deal with many different teams all over the place, distributed development is something that concerns me. Agile, with or without a capital-A, I am more interested in from a theoretical point of view. Again I think comming to this from a standing start, it wasn't going to tease much out.

(Klaus Marquardt) Patterns for Versions, Releases, Compatibility Every time I saw Allan Kelly this conference he was talking about tactile real things. Very fashionable amongst the sort that like wearable computers I believe. So we had cards with order imposed by a piece of string. A workshop that could easily fall apart but kept together. I still don't like reading handwriting. As ever, I hope something came out of it that could be abstracted.

Enigma Challenge:

I have to say I tried and failed. Got the time wrong getting up on Saturday morning, and had a go at it with pencil and paper (I did have them available). Not many permutations and some very clear data. Must have misunderstood some piece of it or have been stupid. I deliberately left before suffering seeing the solution.

You can tell Stephen Colebourne is a real programmer - his laptop is an Inspiron. Yesterday evening I popped down to Stephen's JAVAWUG presentation on the Fan programming language.

Fan is an attempt by Brian Frank and Andy Frank at a simpler Java-like, imperative, general-purpose language. It is statically typed, but leans heavily towards the implicit. A number of features implictly hide errors. I believe the main reason explicit[1], checked exceptions are disliked by the masses is that the vast majority of programmers only want to handle the happy case. My main problem with checked exceptions is that Java is lacking in support for layers. Some of the features to support the actor model of concurrency are strong, but as an inexperienced, non-expert I feel that the model is too restrictive.

A few small language changes are not going to make a significant boost to productivity (although the wrong change could seriously damage it). Productivity is about good programmers in a good environment. Almost every change Fan makes is not to my taste. However, like Java did to C++, exploring areas that can be chucked out of the mainstream has to be a good thing. Anyone else want to have a go?

As languages have progressed up to Java, the fruit has got harder to pick (see Brookes). Anything that seeks to replace the Java-like languages will need to achieve gains in many areas. That means replacing clusters of features, not just feeping creaturism.

^[1] It would be possible to have implictly checked exceptions. They would probably still be disliked, but those haters would tend to be less vocal in their grumblings.

(Including: How I got a stern talking to from the fuzz.)

James Ward on ActionScript for Java Developers. An entertaining duo presented a comparison of Adobe ActionScript 3.0 and Java. A little bit more detailed that comparing keywords, but not much. It rather lacked the whys and the ways you might use the language. It also deliberately overlooked the differences between ActionScript and the JavaScript/ECMAScript/LiveScript/JScript versions of Scheme.

Brian Leonard on Developing Beyond localhost. A slick presentation with the lightweight (as in beer), free (not as in beer) VirtualBox virtualisation software, also featuring NetBeans and ZFS. ZFS allows quick restoration to virgin state with relatively little physical disc usage. So, apparently an easy way to test multihost setups. I should probably be looking at this myself. Can I get ZFS for Vista?

Adam Bien on EJB 3.1 - From Legacy To Secret Weapon. So why wasn't EJB 1.0 something like this? Of course, Java has much competition around this space. As acknowledged in the title, EJB has had a bad reputation (that used to be well deserved). EJB 3.x puts in a strong showing, but I'm sufficient removed to not have a useful opinion.

Overall impressions: There was a bit too much marketing B.S. in the sessions and a lack of new technical content (with the notable exception of some of the Sun presentations). For me, this conference ranks someway above the more expensive Jazoon in Zurich, but way below the more technical ACCU in Oxford (although Jazoon has better wifi than Devoxx, which is better than ACCU). I will be here next year, even if I have to pay for it myself.

(Metropolis is out of town through an area of town you probably wouldn't usually go through. One thing that is immediately apparent about Antwerp is that the traffic lights are pedestrian hostile. You can stand there waiting to cross the street with nothing coming for ages before the little man turns green (the locals tend not to). I've known some individual lights bad for that, but Antwerp takes the idea and runs with it. So anyway, see a nice big gap with cars approaching in the distance at a steady speed, so cross the road. As it turns out, the cars may have been going faster if the lead car wasn't the police. So I was stopped and questioned. I didn't have ID papers on me (is that mandatory in Belgium? Makes giving an on the spot EUR 50 fine difficult?). I was let off with a stern telling off for crossing a road in the normal manner.

I continued on my way, following behind someone who may also not have been local. It was fine until the pavement stopped on a raised section. Some steps led down to some barricades and a slightly dishevelled man urinating. After some indecision I made may way down. Getting out was made easier because most of the handrail was missing.)

The keynote introducted by Stephan Janssen. Yeah, the wifi sucks. Actually it isn't so bad today and there appears to be more laptops out. Everybody autodownloading Windows patches yesterday? Fortunately no beatboxing today. (Just a hint: Audience participation. People here are mostly geeks. Therefore likely introverted. Strangely, introverted people tend to produce far more saliva than normals (caused by the same gene apparently, although I guess things are never really that easy - anyone from a gene thingy company?). Lots of saliva sloshing around all around me is most distressing.

Joshua Bloch on Effective Java Reloaded. A keynote with like proper code. I guess you already know what he does. Buy the book, even if you have the first.

The using a single element enum as "singleton"* item: You don't actually need the non-transient field to perform the stated hack in the original version - just create the serialised data with a field included (hint: don't try this with a hex editor). In the enum version, the class also brings along with it all the methods from Enum, and you can't extend (not until JDK7 gets a small language change to allow abstract enums, perhaps). If you don't mind the extra methods, why not also use this for utility classes if you have them: enum MyUtils {; public static ... }?

Mark Reinhold on The Modular Java Platform. Ooh. New stuff about modules, as in packaging rather than language and access. Another refreshingly technical keynote.

Instead of jar hell, we now have pretty graphs that are represented somehow. Plus we have some kind of inheritance/implementation. It is not clear how interfaces that use types from other modules are going to be represented. Just use god's own integers for all your needs? So "JDK" implementation modularised, and at least one interface module for "Java".

Also, very noteworthy: Possible breaking of backwards compatibility. Or something like that.

Brian Goetz and Alex Buckley on Towards a dynamic VM. Stuff for making the JDK the first choice for running the multitude of dynamic language. A high-level look at the low-level details. I'm now even more confident that I don't know what is going on here. Absolutely nothing to do with the session but: buy Brian's book, JCiP.

Jean-Francois Arcand on Introduction to NIO.2 (sic). Slides had a slightly different title about Asynchronous IO. Indeed most of the presentation was on the Asynchronous part of More NIO Features, together with its use in Grizzily. The file part of the API wasn't in scope. I guess for most people interested in Asynchronous IO, Grizzily will probably be a more appropriate choice in order to avoid dealing with all the low-level details. That's been a theme of the day up to now - background information which goes on at a lower level, so now you know that you don't have to worry. And perhaps what you do need to worry about. Nice to know that this new API will come with an implementation in better condition that the 1.4.0 java.nio was released with.

If you do drop down to java.nio the Asynchronous IO will probably be easier to use than the old new IO. Some gotchas (check the slides or similar for details - do not trust me). Fixed thread-pools can run in to deadlocks if, er, you queue tasks into a fixed queue or wait for tasks and you run out of threads. I think unbounded thread-pools grow if tasks are added without free threads. So that'll be more threads if you're running slowly, and creating threads will make the system run even slower. Another issue is that a buffer is in use whilst waiting for the remote peer to respond. The (direct) buffers are (non-Java heap) memory. This means you could be using much more memory than if you were using selector (Jean-Francois was even paranoid about attachment sizes on the "old" SelectorKeys).

Dick Wall and Carl Quinn with Joe Nuxoll a pixellated Tor Norbye in JavaPosse.com LIVE. Yay! Not sure that shouting out is a more accurate than the whiteboards. Free Atlassian beer helped (thanks!). Tor Norbye disappeared into inescapable pixel-hell when he switched to NetBeans.

Mahmood Ali on Preventing bugs with pluggable type-checking for Java. A short session that I managed to arrive slightly late to. Optional pluggable type systems seem a promising concept. The implementation here used the annotation system (with possible JDK7 annotations of generic parameters) to do things such as null-checking and taint tracing. Not sure how sound this is (nulls are observable from incompeletely initialised objects, for instance, and there's problems with implementations of collections). It's a great shame that Gilad Bracha and Peter von der Ahé's Newspeak has lost funding.

Paul Sandoz on JAX-RS: The Java API for RESTful Web Services. I was skeptical about annotations when I first saw them. Not the point of this session, but it's nice to see them here. I'm still skeptical over XML as a programming interface, but if you are going to go for this why not leverage JAX-WS/SOAP which has the heavy weight all handled for you.

*Singleton is in quotes because "real" singletons have two features: the provide a single point of access and contain mutable data. Mutable data in a static is, of course, evil. However, it is a useful approach if you are implementing an interface (not Java keyword) with a stateless implementation. For instance a sink OutputStream.