The elements still holding back web.xml

While both JavaEE and Spring would like you to believe that you no longer need a web.xml file in your projects, that is not true. Here are a couple elements/configurations that are simply not available through Java Configuration.

1. Session-Timeout


Yes, there is no way to specify a session-timeout using Java configuration.

Related Spring Bug:

2. Execution order of filters


There is no way to guarantee which order your filters execute in unless you specify them in a web.xml file. This can have dire security consequences with your authentication filter being executed after some security sensitive filter or being skipped entirely due to some previous filter in the chain.

Related Spring Bug:

Vote for bugs
I dont know where to file a bug for JavaEE, but I have linked to the corresponding bugs for Spring and hopefully they will be fixed in the next release so we can actually get rid of the dreaded web.xml file.

Java 8 lambda error messages are the new C++ templates

Java 8 lambda error messages are the new C++ templates

The major problem with website

While has a cool new design:

There are still things fundamentally wrong with the website in that it seems to cater to developers of eclipse rather than users of eclipse.

For example, expanding the ‘Detailed features list’ for Eclipse IDE for Java Developers, I see:

Can someone explain the feature org.eclipse.epp.package.common.feature and how it is different from org.eclipse.equinox.p2.user.ui

WebStorm 8 TypeScript Support Review

I think TypeScript is the most important thing to happen to Javascript yet. All of the frontend of DripStat is written in TypeScript. So a good cross platform TypeScript IDE is important to me.

I have previously written about how weak WebStorm is, especially given the high quality of the rest of Jetbrains’ products. However, I have waited for a long while to write this for a couple reasons:

  1. TypeScript wasn’t at 1.0 yet

  2. WebStorm 8 was right around the corner.

Now that TypeScript is at 1.0.1 and WebStorm has released 2 revisions (at version 8.0.2 now), I think its high time we see how good WebStorm’s support for TypeScript really is.

1. Refactoring that screws up your code

This is the worst for me because in this case using the feature of your IDE actually results in your code being incorrect. Its one thing to not have features/buggy features in your product, but another to fuck up your user’s code. The fact that Jetbrains has not bothered to fix it doesn’t give me hope that they care about TypeScript. Some examples:

Extract method

Extracting a method always creates an incorrect function definition. It creates a javascript function instead of a TypeScript function This is 100% reproducible.


This quite literally does nothing

Change Signature

This puts a weird internal text next to your function, which obviously is incorrect code.

All these refactoring bugs are 100% reproducible and of course these are just a few examples. If Jetbrains doesn’t want to support these refactorings, it should just remove them from the available options. There is no excuse for screwing up people’s code.

2. Code completion cant even detect globals

A global variable declared in a file, when referenced in another file is not available in the code completion list

3. No auto referencing

Both Visual Studio and Eclipse TypeScript plugins will detect the typescript files in a project and automatically make the symbols of each file available in other, regardless of whether its manually referenced or not. This is needed because while you may have the code split across files, during the build stage you may end up concatenating those files, thus not needing to manually reference each file.

Webstorm however will just mark your file full of errors if you don’t include all the files that are referenced in each file.

4. No Syntax coloring option

Yes, you read that correct. There is no way to change the highlighting of your TypeScript code!

My Webstorm highlights class names with red. Red is also what Webstorm uses to highlight incorrect symbol names in your code.

Thus scrolling through code I now have no idea whether the red I see is correct code or not.

Related bug
Its only about 17 months old…

5. Editor wont recognize method overloads

The editor does not understand method overloads.

As you can see in the image, the method separator line is shown for each of the oveloads (it should just one for the entire constructor, including overloads). This means when you tell Webstorm to format your code, there will be extra newlines between the overload definitions, thus screwing up your formatting.

6. Slooow compilation

In Visual Studio, I just save the typescript file and the corresponding javascript is generated instantly. There is no build progress indicator and its not needed either. Its so fast it could probably show the generated Javascript as I type.

WebStorm is a different story however. The same file when saved will show a progress indicator at the bottom for many seconds showing the file being compiled.

Maybe its because they use the awful File Watchers, instead of a more integrated system. But either way, the end user experience and speed of development is highly impacted due to the slow build time.


WebStorm’s support for TypeScript is close to non-existent. Heck, you cant even change the syntax highlighting! While TypeScript is designed to make Javascript be useful inside an IDE, WebStorm’s highly buggy support makes you not want to trust it for anything. This is specially true after you have seen it screwing up your code after refactoring.

Bottom line, if you are using TypeScript, don’t use WebStorm. Eclipse remains the only usable multi-platform TypeScript IDE.

Changing font in Skitch

I was recently googling how to change the font of the text widget in Skitch and found this answer :


This seems really basic, but I can’t for the life of me figure out how to change the text’s font in Skitch. What am I missing?

Evernote employee: You currently cannot change the font. This is on our long-term roadmap.

That post is over a year old. Must be quite an engineering challenge…

UX Design Disasters: Stormpath

While Stormpath claims to offer ‘User Management’ in all their online ads, sadly after using their service on DripStat, that is exactly what we have lost.

Here is an image of Stormpath’s dashboard to ‘manage your users’.

Yes, thats right. If i want to see details of any user of DripStat or perform any function on it, I have 2 choices:

  1. Click ‘next’ at the bottom of the page. Browse through all the 20,000 users of DripStat, 25 at a time, to reach the ‘one’.
  2. Write a custom program to do that.

Utter UX Fail

On a scale from 1 to 10, this is UX fail to 11. User management is the core service that Stormpath claims to offer and even after many months they haven’t bothered fixing such a critical issue with their interface.

If we had just created a ‘users’ table in our database, life would be so much simpler…..

Firebase’s Java SDK will screw your app server and deployment scripts

We use Firebase a ton at DripStat. So I am sad to see firebase basically not giving a flying f**k about their Java SDK.

Your web applications can no longer shut down

The Firebase SDK creates background non-daemon threads, so when you try to shutdown your apache tomcat using the ./ script, it wont. Your tomcat will continue running until you manually use the kill command on the process to kill it.

Deployment processes get screwed

Any tool/script that executes ./ on your tomcat server to kill it, will result in crazy errors cause while the script will execute and think tomcat is terminated that won’t in fact be the case. Tomcat will continue running until its manually terminated as described above.

Even in development, an extra step to remember

It even screws your development, since no longer does pressing the ‘Stop’ button in Intellij terminate Tomcat. You have to remember to ‘kill’ tomcat using a separate button after you press the stop button.

Website has no info

Not only that, the website has no changelog or version history of their sdk artifact making it impossible to know when the sdk is updated and with what changes.


It is surprising that Firebase has completely ignored such a major issue which impacts both development and production time continuous delivery processes.

Guide on using Java 8 in Eclipse

An engineer from Zeroturnaround writes that he had such a bad experience enabling Java 8 support on Eclipse, he switched to Netbeans.

However, it took me 4 days after Java 8 release to find a blog post about the topic, which in turn refers to another message, which then points to a Wiki page that describes Eclipse’s support for Java 8. ) that refers to a message on the JDT mailing list which in turn refers to a Wiki page where a how to for Eclipse Java 8 support is described.

I am just assuming that he sucks at looking up stuff. Here is how to ‘find’ and enable Java 8 support on Eclipse:

1. Go to and read the topmost headline

2. See full page with instructions and images

Is that so hard….

UX Design Disasters: Perforce Eclipse plugin

The Perforce Eclipse Plugin has the P4 Pending Changelists view to see your changeslists and submit them.

The toolbar has a bunch of buttons. But its missing a key one.

So umm how does one actually ‘submit’ a changelist??

The button you want to use 99.9% of the time is hidden in the right-click menu…

This is what happens a product is designed by someone who doesnt use it himself.

ASM framework 5.0: The missing migration guide

I just upgraded both DripStat and Chronon to ASM framework 5.0 to support Java 8. Apparently there is no migration guide for upgrading from asm 4 to asm 5 which caused a ton of issues.

Here is the list of those issues and their solutions so you don’t have to face them too:

1. Change to Opcodes.ASM5
Everywhere that you pass Opcodes.ASM4, replace with Opcodes.ASM5. This one is the most obvious.

2. Change onVisitMethodInsn() overrides
This one will cause you tons of subtle runtime bugs if you don’t know about it.

ASM 5.0’s MethodVisitor contains a new visitMethodInsn() method with the signature:

void visitMethodInsn(int opcode, String owner, String name,
  String desc, boolean itf) 

Note the addition of the last parameter boolean itf which is to support default methods in Interfaces.

If you pass Opcodes.ASM5, the MethodVisitor class will only call this method. So your pre asm 5 code that uses the visitMethodInsn() method without the boolean itf parameter will never be called! Of course, this means that your code will compile and you won’t even get a RuntimeException. Just that since your visitMethodInsn() is never called, you will have bugs in the instrumented code.

Replace overrides to visitMethodInsn() with the new version. Your IDE should be able to help you here by marking the previous version of the method as deprecated.

3. Changed your ClassNode subclasses
Do you have a class that extends from ClassNode like this:

class JSRInliningClassNode extends ClassNode {
        public JSRInliningClassNode() {

This will cause a RuntimeException because ClassNode's no-arg constructor looks like this:

public ClassNode() {
        if (getClass() != ClassNode.class) {
            throw new IllegalStateException();


Use the constructor that does take an argument, the code should be like this:

class JSRInliningClassNode extends ClassNode {
        public JSRInliningClassNode() {

4. Use asm 5.0.1 atleast
ASM 5.0.1 was relased just a few days after the 5.0 release and contains some critical bugfixes. Make sure you use atleast that version.

Have fun!