One of the headline new features in OpenAM 13 is support for Stateless Sessions, which allow for essentially unlimited horizontal scalability of your session infrastructure. This is achieved by moving session state out of the data store and placing it directly on the client as a signed and encrypted JWT. Any server in the cluster can then handle any request to validate a session token locally by simply validating the signature on the JWT and checking that the token has not yet expired (using the expiry timestamp baked into the token itself). Stateless sessions are not in themselves a new concept, and there are a handful of implementations out there. You may be thinking “Great! Where do I sign?”, but there has been an Achilles’ heel with stateless that has held it back from being truly production-ready — how to handle logout. The general advice is that stateless logout is very hard or impossible. Well, we’re not afraid of a bit of hard work at Forgerock, so we decided to solve that problem. In this post I’ll tell you how we did it.
The GCHQ Christmas card puzzle has had us all scratching our heads at Forgerock Engineering in Bristol this week (well, that and trying to get OpenAM 13 ready, on which more to come soon). Some colleagues have solved the first part by hand. As a lazy programmer though, this seems like such a waste of energy. What if I ever want to solve another such puzzle?! So I decided to solve the puzzle automatically, and constraint programming seemed like the obvious approach as the puzzle is effectively a set of constraints over the shading of a grid. Warning: spoilers ahead if you’ve not solved the first stage already. Continue reading “Solving the GCHQ Christmas puzzle (part 1) with Constraint Programming”
There’s been a lot of discussion of the potential dangers of Artificial Intelligence (AI) recently, as an existential threat to humanity. I think this overplays the risks, but also rather over-estimates how close we are to such an outcome. Some modest recent advances in pattern recognition are little more than baby steps along a path whose end we cannot even clearly define. More importantly though, I think there are two much more likely outcomes of any emergence of general “human-level” AI that pose significant ethical questions:
- Rather than enslaving us, we create genuinely sentient AI and enslave it. This seems a far more likely scenario to me, given humanity’s record so far. Can an AI be “human-level” and yet treated as sub-human?
- Near human-level AI creates immense economic value, while demolishing the market for human labour. Our current efforts (in the UK at least) at dismantling the welfare state and racing to the bottom on corporation tax start to look a little short-sighted from this perspective.
This blog post is a re-posting of my recent answer on StackOverflow regarding ThreadLocal objects and supposed PermGen memory leaks. Essentially, despite what Tomcat may say, ThreadLocal usage in a container is not always a memory leak. Repost of my answer below the line:
Every now and then I discover a new class in the Java standard library that I’ve not needed to use before. Today, that class was CopyOnWriteArrayList (or rather the CopyOnWriteArraySet wrapper). This is a good choice when implementing a set of subscribers in an observer pattern, as typically the set of subscribers doesn’t change very often but we iterate through the set regularly to broadcast events. The COW implementations are optimised for exactly this case, as the iterator only hits a volatile read rather than needing a lock.
Being curious, I decided to have a look at the implementation of this class to verify that it behaved as I expected from the docs. Sure enough, everything is as I would expect. However, something did stick out immediately as a bit odd. Continue reading “The curious case of transient final locks and CopyOnWriteArrayList”
Now that the dust has settled on the launch of Java 8, we can begin to see the benefits that all these new features will bring to those of us willing to throw off the yoke of corporate oppression and start committing lambda expressions to a “Java 5” code base. The possibilities that lambdas bring, along with default methods, and the startling addition of static methods in interfaces are real game changers. For instance, it is now possible to write an entire Java application in a single interface! Those of us who have long railed against the tyranny of a single-class-per-file can now rejoice at being able to place all of our logic in a single file, and it doesn’t even need to be a class. As you will see from this post, the future is here and it is beautiful.
We had a competition at work to calculate the count and sum of all prime numbers between 1 and 1,000,000 in the shortest time. Naturally we all went for the Sieve of Eratosthenes as the best way to implement this. The fastest solution was a straightforward imperative approach, but I came up with the shortest implementation using Java 8 streams and a BitSet that comes within about 20% of the winner. It’s quite cute so I thought I’d share it. Note: it uses a stateful consumer so cannot be parallelised. I’d love to see a good stateless version if anyone can think of one.
There seem to be lots of new programming languages popping up at the moment. Clojure, Scala, Opa, Dart, Go, Rust, and so on. I’m always a fan of new programming languages, as I feel there is still so much untapped innovation to explore. However, it can take years, or even decades for a new language to reach commercial acceptance (a sad reality). In the meantime, mainstream languages can incorporate proven features from more experimental cousins. Java, for instance, has adopted generics and annotations, both features I have some fondness for. In the spirit of encouraging further progress I offer the following as a list of largely conservative enhancements to Java that are in keeping with it’s fundamental design as an imperative object-oriented language. I don’t wish to turn Java into Haskell, because Haskell is already good enough.
So, here’s my top five “easy” extensions to Java:
A new month a new job. I’m now working as a Java Application Developer for a large software consultancy. I’ll be developing Java EE applications for this job, which will be an interesting experience. I’m keen to really get my hands dirty with what is currently the de facto standard for building large business apps.
My first challenge is to get to grips with the Java Persistence API (JPA), which provides a standardised object-relational mapping (ORM) for Java applications. Basically, it takes a bunch of annotated Java classes and determines how best to map these to a relational database, taking care of foreign key constraints, inheritance, joins, and so forth. On the surface, this is all very good. Current best practice in developing these kinds of apps is to separate out the data model of the domain into a layer of simple Java beans (i.e., objects with properties and little custom behaviour), so something like JPA makes this much easier to knock together than using JDBC directly. (Although, it’s not that hard to use JDBC). Continue reading “Relations ain’t “flat””