Implementing HTTP/2 push in Java

This is another guest post by my friend Tobi. —Jörn

The story:

Some months ago I started to play around with HTTP/2 and wondered what should get better with this piece of technology, where are the limitations and pitfalls. So I first went to Wikipedia and read the Wikipedia article about HTTP/2 and the RFC 7540 standard. I was quite impressed about the idea to reduce the latency of web pages.

Because I am familiar with JEE development I just had a look at how to integrate this technology in an existing JEE application and read about PushBuilder API. Cool – a Java API which handles to push resources before the actual response is submitted to the client. I thought this sounds good and build up my first application with it.

First I tried to configure tomcat with SSL and HTTP/2, but I failed sadly as you can read within this mailing list topic Apache Tomcat 9.0.0-M4 and http/2 on Mac OS X 10.11.4 (If you have any hints what I did wrong please let me know!). Then I tried it by configure a Jetty Servlet Container which was a great straight forward implementation as you can see in this Sample.

Ok the first implementation was made.

Then I had a look into the console of my browser and saw the resources are pushed all the time and I thought this might cause a big impact on the network traffic which outweighs the latency benefit. So I posted a question at stackoverflow about “Jetty respond with status 200 instead of 304 while using http2” and happily Martin Grigorov (Tomcat Committer) and Simone Bordet (Jetty core developer) helped me within this question and a corresponding issue ticket jetty.project issues 801 to understand that it is up to the developer when a resource should be pushed and when the browser should use the cache. One sentence I want to quote: “I think there is a misunderstanding of what the push APIs do. Right now, they just push.”

By consolidating those new information I came up with a new Implementation for Apache Wicket to handle HTTP/2 push very easily. You can find the implementation in the corresponding PushHeaderItem class in the wicket git repository

Here are some facts / pitfalls that you should consider when using HTTP/2 push:

  1. Think about when should resources be pushed and when it makes more sense to get them out of the browser cache with a minor “overhead request” – depending on this you have to build up your own implementation
  2. Some browsers like Chrome do not cache resources if the SSL cert is self signed – consider this if you check the caching behavior of your implementation
  3. Try to implement your push API docile so that the browser can also use HTTP/1 and get the resources in a normal way as fallback
  4. You can check the push behavior of your implementation / example application. Chrome example: chrome://net-internals/#http2


When using HTTP/2 and PushBuilder API you have to think about a lot of marginal conditions like Caching, SSL implementations, traffic impact to find a good solution that does exactly what you want.

Release: Validation Plugin 1.15.1

I’m happy to announce the first patch release for the jQuery Validation plugin 1.15.x series.

11 people helped out to add a few enhancements and fix some bugs. Kudos to all of you, namely: adhayward, Bill Sorensen, Brahim Arkni, Hugo, Huseyn, Jordan Clark, Markus Staab, Michael Hohlovich, svrx, TLib and Torgny Bjers.

This is another release which would not have been possible without the help of Brahim Arkni. Thanks again for your support!

For a full list of all the changes, check out the changelog below.

Download this release.

  • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
  • Please post bug reports and other contributions (enhancements, features, e.g. new validation methods) to the GitHub issue tracker

The full changelog:


  • Fix multiple mime-type validation
  • IBAN require at least 5 chars (Closes #1797, Fixes #1674)
  • Correct notEqualTo jQuery reference


  • Added failing test for #1805
  • Fix group validation with 3 and more fields
  • Fix regressions introduced in #1644 and #1657 (Closes #1800)
  • Update step validation to handle floating points correctly
  • Fix error when calling $.fn.rules() on a non-form element
  • Call errorPlacement in validator scope
  • Fixed issue with contenteditable elements in forms where events for single input validation would cause exceptions


  • Add links to Bootstrap and Semantic-UI demos to index.html
  • Use .on() instead of .validateDelegate()


  • Added Azeri language


  • Added regression unit tests for PR #1760

Computer science research ideas

Every now and then I get emails from computer science researchers (often students), asking me to participate in their particular study. Sometimes I participate, sometimes I don’t, often I’m thinking to myself: Couldn’t you ask me what you should be researching in the first place? While that is an inappropriate response for these emails, I wanted to write down my ideas for researchers, in public, so that they can either find them on their own or I can at least link to them.

Since I’ve been doing mostly JavaScript development in the last few years, with about 80% of that in the browser, my perspective is mostly from that platform. Though I expect that a lot of these ideas can be applied to other platforms as well.

If you have ideas that would fit in this list, let me know.

Testing tools

How can better testing tools help write better software? This area seems to have so much untapped potential. Most open source testing tools are developed and improved in very small increments, the “this feature would be with this use case”, but it’s rare to find features that make big leaps. While I still haven’t used it, Intern is an interesting tool, because it integrates all kinds of frontend testing use cases into a single suite, and usually integration, especially if we think of it as fusion, can set free extra energy.

One example of a feature in a testing tool that is rather unlikely to happen in regular open source development scenarios is the reordering feature in QUnit. It’s not a well known feature, since its behaviour is rather subtle. It might also not be as useful as I’m thinking it is, since I haven’t been able to do any research to verify that. But I think it’s an interesting example anyway. And since I came up with it (more or less) and implemented it, I can tell you how it happened.

Some years ago, I was listening to a podcast, with Kent Beck, one of the original authors of JUnit, as a guest. He was talking about a project he had been working on for some time, called JUnit MAX. It was a plugin for the Eclipse IDE, providing a better test runner. One significant feature of this plugin was its reordering of tests after previous runs. Kent was talking about how research showed that the odds of a failing test failing again on the next run are much higher then for a passing test to start failing. So for shorter feedback loops, it makes sense to run tests, that previously failed, first on the next run. JUnit MAX would also consider the time it takes for various tests to run, and run the fastest failing tests before the slower failing tests.

After hearing that, I figured that I could implement a subset of that feature in QUnit, reordering test runs, based on previous failures (ignoring the secondary sort on runtime). While it required some rather complicated changes to make the queue flexible enough for the reorder and maintaining the original output order, the result was a faster feedback loop with no additional effort needed by the developer using QUnit. The only time this failed was when tests weren’t atomic, that is, test B relied on test A running first. Non-atomic tests are a significant code smell by themselves, and in way this feature helped uncovering them. In the end, it still required an option to turn the reordering feature off.

I’m optimistic that there are plenty ways to write better testing tools, and academic research could provide ideas and do verification of those ideas.

Error messages

“undefined is not a function” is a terrible error message, but its not even the worst you’d ever run into when writing JavaScript for browsers. “Script error” without a stacktrace definitely is worse, but hopefully not occuring anymore.

Elm is known for spectacularly good error messages, almost obsessively improving the compiler, even with a separate repository collecting “broken Elm programs / data to improve error messages.

I’d love to see a researcher doing some ground work like this for JavaScript, collecting errors across browsers and serverside runtimes, and at least filing issues to improve these messages.

Bug reporting

Consider these two scenarios.

Scenario A: You get an email with the subject “the site doesn’t work”, and no body. You don’t even know which site this refers to.

Scenario B: You get an entry in your issue tracking system, with some descriptive fields, but most importantly, a link. You click that link, which brings you to your app, along with some debugging tool. One element of that tool is a slider that lets you go back in time. It also shows you various relevant variable. Going back in time you can see what interactions the user did before running into the issue they reported. You can quickly identify the issue based on the steps and the state of the system.

Now, which of these two would you prefer if you get paid for solving issues (not so much for spending time on solving them)? Scenario B supposedly is also something Elm provides (or at least helps with). But I don’t see why other platforms shouldn’t be able to provide at least partial support for that kind of error reporting and debugging.

Code Review

If a code review finds no issues, does it mean that the reviewer didn’t bother looking too much? Or that there are no issues? How can you review the reviewer? Are there metrics or tools that could help become better at reviewing? A reviewer that points out a lot of style issues might never catch actual bugs. A reviewer who always ignores styles issues might have a hard time catching bugs due to style issues.

This seems like an area with a lot of untapped potential, but its hard to tell without some research.

Working remote

Collaborating within a team can vary a lot by physical difference, from pair-programming at the same desk, to being on different sides of the planet in wide apart timezones. There are a lot of options in-between those two extremes. Martin Fowler does a great job of explaining the various options and some of their strengths and weaknesses in Remote versus Co-located Work

There isn’t a simple dichotomy of remote versus co-located work, instead there are several patterns of distribution for teams each of which has different trade-offs and effective techniques suitable for them. While it’s impossible to determine conclusive evidence, my sense is that most groups are more productive working in a co-located manner. But you can build a more productive team by using a distributed working model, because it gives you access to a wider talent pool.

In my experience, once you’ve built a team where everyone can work remotely, you get the benefits of that model even if parts of your team are (sometimes) together in one room. For example, assuming a core team of 5 people shares an office. Every other week one of those people needs to work from home, to take care of family, dealing with home repairs, or one of many other reasons. Usually these activities don’t need an entire day off (and they’re not real vacation!), so being able to work from home just as effectively as in the office makes this much less of an issue.

That said, how to actually build an effective non-co-located team has no clear answers. There are various technical solutions that I found working quite well, but I’ve never done any research to evaluate the ones I’m using or studying alternatives. Coming up with a list of options and ways to evaluate them seems like an interesting research topic to me. Only some of this is specific to software development. For example, communication tools that can properly format and highlight code snippets or error logs are more specific for developers.


All of the above have changed over time, and the bug reporting scenario B I described above has supposedly been possible with Smalltalk years (decades?) ago. I suspect that there’s a lot of history to study in software development even in just the last 10 years. From a historian’s perspective, the whole industry might be too young to study effectively, but that shouldn’t prevent studying trends like “best practices” in architecture, tools, project management, design, or any of the topics mentioned above. A good example is the Born for it article on, looking at “How the image of software developers came about”.

A big thank you to Enes Fazli for reviewing drafts of this article.

OSX software, five years later

In November 2010, before my first MacBook even arrived, I asked Twitter for “must-have” OSX software and collected the results in a blog post. A year later, I posted an update with a list of OSX software I was actually using. A few more years have passed since then. Last year I switched from my original MacBook Air to a MacBook Pro (a very good decision) and used the opportunity to do some cleanup. About 9 months into using the MBP, I figured I could do another list. An asterisk indicates something I didn’t have on my list in 2011.


  • Chrome, as my regular browser and part of my web development environment, with these extensions:
    • 1Password
    • uBlock Origin*, currently the most decent adblocker. Will see how long it can stay independent.
    • RSS Subscription, restores the RSS icon
    • BrowserStack Local*, provides tunnel for testing local files
    • Pinboard*, quickly add open tab(s) as bookmarks. Also using Pinboard on my phone.
    • Social Fixer for Facebook*, makes a few features on Facebook a lot less annoying. Hasn’t been updated since December 2014 and accordingly falls short in many places, but even and outdated and sometimes broken extension is still preferable over vanilla Facebook to me.
  • Keynote, these days used very rarley. My last few conference talks were all web-based, with probably too much time spent on customizing the template I used.
  • Twitter for Mac, runs only when I need it. Mostly reading Twitter on my phone.
  • 1Password to generate and mange passwords. Chrome integration is nice, runs also on Windows PC and Android phone.
  • Tunnelblick for VPN connections. Depends on the project I’m working on, has seen lots of use more recently.
  • DaisyDisk*, quickly tells me where most disk space is used. This was very useful on my old MacBook Air, where the 256 GB SSD was full way too often. With 512 GB this is much less of an issue.
  • Dropbox*, weird that it wasn’t on my previous list from 2011, I’m pretty sure I’ve used that before.
  • ScreenFlow*, pretty decent software for capturing screen casts. I’ve mostly used it to record screenreader sessions for my Talk to Me – Making websites accessible presentation. I also used it to record that presentation, since its able to capture both the camera input and the projector screen output.
  • Very special purpose:
    • Seil* (formerly know an PCKeyboardHack), for remapping the capslock key to toggle iTerm2. To do this, use Seil to change capslock to keycode 105 (also follow the instruction for turning off the default behaviour). Then in iTterm2, go to Preferences -> Keys, under “Hotkey”, check “Show/hide iTerms2 with a system-wide hotkey”, click on the input and hit your remapped capslock key. It should enter “F13”. Then close Preferences and give it a try.
    • SizeUp*, for maximizing windows and moving them from one desktop or monitor to another


  • Skype, still using it almost daily to chat, talk, and sometimes pair-program via screensharing. Something like once a month someone can’t hear me, but restarting Skype always fixes that issue.
  • Gitter* is like Slack (I guess), but focused on coding projects, with very tight GitHub integration. Currently using it with multiple chat rooms to work on I created a jquery-validation channel, but it has seen very little use. I’m looking forward to the day where they’re rewriting it as a native app, or at least fix the performance. Switching channels shouldn’t take several seconds for the new channel to render.
  • LimeChat* as IRC client, using isaacs’ theme
  • Telegram*, using the “native” OSX app, which supports secret chats, something the cross-platform Telegram Desktop app doesn’t have.



  • iTunes for music playback. Overall its still decent, even with the tons of irrelevent features cramped into the same app. I’ve never found an alternative just for playback of tagged mp3s files. I often listen to all albums of a single artist in chronological order or shuffled albums (not just songs). Would need at least these features to be able to replace iTunes.
  • VLC for video and occasional audio file that I don’t want to add to iTunes.
  • Picasa for photos, a quick import and edit while traveling. May need to find a replacement, since the desktop app won’t be updated anymore.
  • Fission*, for cutting MP3s very efficiently. Unlike a lot of other software, Fission can cut compressed audio files, without decompressing them first and recompressing them later. Great to cut rehearsal room recordings down to the relevant parts.
  • Guitar Pro*, for writing down songs. A very recent addition, and a bit weird to use a current version after using Guitar Pro originally about 10 years ago. They’ve added a bunch of emulated instruments, unfortunately all on top of midi instruments, which mostly sounds pretty terrible. Still useful to pin down the little details of songs and share them with the rest of the band.

Thanks to my friend Enes for reviewing a draft of this post.