The Pragmatic Coder The blog of Richard Nichols.

Automatic Javascript and CSS Compression For Java Webapps

One of the “no brainer” ways to make your web sites / web apps load faster for users is to utilise Javascript and CSS compression.

This means at least, stripping out all the white-space, comments and other non-essential character data from your files, but can also mean code compression / obfuscation as well.

One of the best tools for this task is Yahoo’s YUI Compressor, which does a fantastic job of compressing down both .js and .css files.

Better yet, it is very easy to automate this compression process as part of your Ant build process for a standard Java web application.

Read on for the details…

We’ll need a couple of add-on JAR libraries; firstly (and most obviously), YUI Compressor, which is available from Yahoo as a single JAR which can be placed into our “lib/” folder of our web project (or similar location – I will assume lib/ for now).

Secondly we will need an add-on task for Ant in the ant-contrib project which allows us to iterate the file system, performing tasks (the <foreach> task). Note, that the sourceforge site for the ant-contrib project is a little confusing, you may have to view “all downloads” to find the actual ant-contrib JAR download.

Again place this download in the lib/ folder of the web project.

Now we can change our build file to compress…

    <taskdef resource="net/sf/antcontrib/antcontrib.properties">
        <classpath>
            <pathelement location="lib/ant-contrib-0.6.jar"/>
        </classpath>
    </taskdef>

    <target name="yuicompress"
            description="Compresses a CSS or JS file using YUI compressor">
        <java jar="lib/yuicompressor-2.4.2.jar" fork="true">
            <arg value="-o"/>
            <arg value="${yuicFile}.comp"/>
            <arg value="${yuicFile}"/>
        </java>
        <move file="${yuicFile}.comp" tofile="${yuicFile}"/>
    </target>

    <target name="-post-compile">
        <foreach target="yuicompress" param="yuicFile">
            <path>
                <fileset dir="build">
                    <include name="**/*.js"/>
                    <include name="**/*.css"/>
                </fileset>
            </path>
        </foreach>
    </target>

The key task to invoke is the “-post-compile” task. This is based off a standard Netbeans web project build.xml, but you can use this in a free-form build.xml just as easily by calling the -post-compile target as a dependancy of your packaging / WAR target.

Essentially after the build step and prior to WAR packaging we compress in-place the .CSS and .JS files in the build folder. The nice thing about this approach is that we can work on human-readable CSS and Javascript in our IDE but deploy compressed content automatically. There is no need to maintain a “myCode.js” and “myCode.min.js” and you can even work with the “non-minified” versions of your favourite API should you wish to as well.

Yahoo!

Markdown Doclet for Javadoc

I spent some spare time this week creating a mash up of sorts… a “markdown” doclet for Javadoc.

Markdown-Doclet Project on Google Code

Markdown is a light-weight markup language which reads much like plain-ASCII-formatted-text, as opposed to HTML which reads like… well HTML.

In fact HTML is pretty damny unreadable, which is why is frustrates me to see developers putting a whole <ul><li>bunch</li><li> of</li><li> html</li></li> <li>tags</li></ul> in their code’s Javadoc comment boxes only to rended it almost impossible to read in the place where you’re most likely to read it (in the code).

The idea of the Markdown doclet is that you can write simple (markdown) text into your Javadoc comments and they will be translated nicely into HTML in your final Javadoc output.

The hardest part of this doclet was figuring out how the hell to patch the standard Sun doclet post Java 1.5. In fact the answer to this is that you need to duplicate the whole damn thing, since they effectively stopped anyone using any part of the current class tree by putting a hard lock into the code.

I was quite suprised at how badly supported the whole Javadoc tool is by Sun. I would see Javadoc as being one of the best out-of-the-box features of the Java platform and probably one of the biggest reasons for it’s wide adoption in the early years.

Anyhow, I have basically glued together the (GPL’ed) Sun doclet (with some changes), MarkdownJ (a Java implementation of Markdown) and UMLGraph.

UMLGraph? – Well I love the UMLGraph doclet which embeds UML class diagrams into your Javadocs. The UMLGraph doclet works by calling the Sun standard doclet and then doing some mods on the files that are generated, so the markdown doclet can work interchangeably with UMLGraph, albeit I had to patch UMLGraph to make that happen, since the Sun standard doclet doesn’t implement any standard interface which would allow a drop in replacement!

I hope other developers can make use of this doclet, and we can keep HTML in our browsers where it belongs!

The 5 Minute Guice Primer

I’ve just finished getting up to speed with Google’s Guice 2.0 and have integrated it into two of my projects. It’s been a very comfortable experience and I could see myself Guicifying most of my Java projects from now on.

To summarise my experiences – Guice is a Dependancy Injection and Aspect Oriented Programming framework for Java. This is the turf that’s normally owned by Spring of course.

So how is Guice different to Spring?

• No XML!
• Narrower scope: Guice only does DI and AOP, unlike Spring which covers a wide gamut of requirements.
• Heavy and mandatory use of annotations.
• …and in my opinion, a more refined and elegant design.

I think one of the main reasons I like Guice so much is the absence of XML. I really hate XML and Guice’s “Module” concept is a great replacement for text configuration. I would be interested to know how often in practice that Spring’s XML configuration is changed in situations where a rebuild of the application is impossible. The argument for that sort of configuration has always seemed like a straw man to me. As a bonus of the Guice Module approach, you get type checking and compilation of your configuration. [It would be interesting to see if someone does implement an XML configurator for Guice though - I'd say it's only a matter of time].

How to get up to speed real fast?

1. If you’re not familiar with DI and/or AOP then do some reading. A framework can only solve a problem that you know you have.
2. Watch the recent Google IO tech session for the 60 minute fast-track introduction.
3. The Guice wiki is helpful, but I found the external links and discussion group to be more helpful.
4. Write something! It’s a dead easy framework to get your head around, and the fastest way to solidify your knowledge is to do.