Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

JavaScript and CSS Concatenation with wro4j

This past weekend, I decided it was about time to fix my YSlow score on this site. I did the easiest thing first by moving all my JavaScript files to the bottom of each page. Then I turned on GZip compression using Roller's built-in CompressionFilter. These changes helped, but the most glaring problem continued to be too many requests. To solve this, I turned to wro4j (as recommended on Twitter) to concatenate my JS and CSS files into one.

I have to say, I'm very happy with the results. I'm now sitting at a YSlow (V2) score of 75; 90 if I use the "Small Site or Blog" ruleset. I believe I can improve this by adding expires headers to my images, js and css. More than anything, I'm impressed with wro4j, its great support and easy setup. I was looking for a runtime solution (b/c I didn't want to have to rebuild Roller) and it seems to be perfect for the job. Furthermore, wro4j minifies everything on the fly and they'll have an expires header filter in the next release.

JAWR and the YUI Compressor are other alternatives to this filter, but I'm currently sold on wro4j. First of all, it passed the 10-minute test. Secondly, it didn't require me to modify Roller's build system.

At this point, if I'm going to implement JS/CSS concatenation and minification in AppFuse and Roller, wro4j seems like the best option. If you disagree, I'd love to hear your reasoning.

TIP: See Javascript Compression in Nexus for information on using YUI Compressor with Maven.

Posted in Roller at Nov 09 2009, 10:44:44 AM MST 16 Comments

wow, thanks for the tip, I was searching for something like this for a while! We use mod_jk to front tomcat with apache and the "compression=on" setting doesnt work for us.

Posted by Sakuraba on November 09, 2009 at 01:29 PM MST #

Recently come across a Javascript dependency management tool called Sprockets ( Then found wro4j from your post.

There will be a busy weekend ahead :)

Posted by thiamteck on November 09, 2009 at 09:42 PM MST #

Thanks for this, Matt. I'd like to use something that does this and more for iUI and I was considering JAWR for concatenating CSS/JS. I'm currently using YUI Compressor at build time. Personally, I'd like to see a comprehensive Java/Rhino based HTML/CSS/JavaScript parsing/manipulation framework that can be used at run-time and/or build time. Is that asking too much?

Posted by Sean Gilligan on November 09, 2009 at 09:45 PM MST #

[Trackback] This post was mentioned on Twitter by alexobjelean: Happy to see that wro4j helped Matt Raible :)

Posted by uberVU - social comments on November 09, 2009 at 10:13 PM MST #

The issue I have with the minification component (and minification in general) is that most tools strip out the comments, including the copyright notices. Which brings up the question: Isn't there a legal obligation to post this information for GPL'd libraries (e.g., jQuery) as party of the code?

Someone else brought up this question on stackoverflow.

It wasn't obvious from reading the wro4j docs whether they address this. Have you seen anything that indicates whether they do?

Posted by Jonathan Gordon on November 10, 2009 at 08:40 PM MST #

@Jonathon From the YUI Compressor documentation:

C-style comments starting with /*! are preserved. This is useful with comments containing copyright/license information.

You may already know this...

Posted by Sean Gilligan on November 10, 2009 at 09:38 PM MST #

@Jonathan sorry, noticed the typo in your name after it was too late...

Posted by Sean Gilligan on November 10, 2009 at 09:40 PM MST #

Hi all,

Before giving my comment, I should say that I'm one of Jawr co-project Leader. I will try to be fair in the comparison of this 2 projects, but we all know that my view is a little bit biased as I know much more Jawr than Wro4j.
So please Alex Objelean don't hesitate to correct me where I'm wrong.

This disclaimer being done, we can say that wro4j and Jawr have a lot in common. The aim of these projects is to provide minified JS and CSS resources to speed up page loading.
They both support development and production mode.
Both of them provide tag libs to reference the bundled resources.

The main difference are :
- Wro4j use one filter, where Jawr use a servlet by resource type.
- Wro4j provides the ability to plug the caching implementation, where Jawr provides a default one.
- Wro4j supports built in CSS variables support.
- Jawr provides a API to generate dynamic resource content, which can be dependent to the user locale. For example, bundle message resources depending on the user locale.
- Jawr provides a grails plugin.
- Jawr supports image caching.
- Jawr supports JMX, which allow you to change the behaviour at runtime. For example, while all other users are in production mode, use one session in debug mode.
- Jawr supports @import in CSS files.
- Jawr provides a way to integrate licences in the generated bundles.
- Jawr provides an easy way set up your CDN or simply put your generated bundle on another HTTP server to speed up your page loading. (For more detail about CDN, please see )
- We are currently working on CSS sprite support, which will be available in our next release.

I will say that the 2 projects have similar goals.
I think that Jawr has more features, but as you know I'm a little bit biased ;-)

In any case, I think that competition is good for both of our projects.
Keep it up Alex.

Kind regards,
Ibrahim Chaehoi

Posted by Ibrahim Chaehoi on November 11, 2009 at 05:45 AM MST #

Thank you Ibrahim for the comment!

Indeed, jawr is much more mature framework and of course has much more features. Wro4j was much more like a limited time & resource project which turned more in a hobby :) in my spare time. As I mentioned in the project home page, it is inspired mostly from jawr and jso. I preferred the jso way of organizing resources in groups instead of building bundles, because I found it much more intuitive.

The way it designed right now, wro4j is very flexibile and extensible. That is why almost any addressed issue can be easily solved. For instance:

1) Regarding the copyright and legal comments issue: By default the comments of the merged resources are removed. This job is done by a PostProcessor called MultiLineCommentStripperProcessor & SingleLineCommentStripperProcessor. If you would like to preserve the comments, you can implement your own Stripper processor (thats very easy: add that new implementation into the chain of processors. This way you can preserve the copyright notices.

2) Wro4j provides the ability to plug the caching implementation _AND_ provides the default one using simple HashMap ...

3) Wro4j provides server-side resource (css, js, images) caching. This is already in trunk and will be released soon. Reviewing jawr code inspired me :)... that is why a big thank you jawr guys!

4) wro4j supports built in CSS variables support and the plans are to support different css meta frameworks which are very easy to plug in.

I don't think wro4j will have same features as jawr very soon and it's not the point The primary goal of wro4j was simplicity and extensibility.

PS: Thank jawr guys for great ideas. I'll borrow them sometime :)

Posted by Alex Objelean on November 12, 2009 at 02:06 PM MST #

Hi Alex,

I also have to say that we have borrow some ideas from wro4j too ;-)


Posted by Ibrahim Chaehoi on November 12, 2009 at 03:38 PM MST #

Hi all, I am one of the authors of Jawr. I think Alex has done a great job with wro4j, it really showed some good ideas and neat patter usage. Still, I'd like to know what you think is missing in Jawr to choose Wro4j over it, as a means for us to improve. I do know you hate the project's name :o)

PS: When I started Jawr, I had this dream that Matt would write about how great it was using it. For real! :'-(

Posted by Jordi Hernandez on November 13, 2009 at 04:09 AM MST #

@Jordi - I wanted something I could add to Apache Roller (which powers this site) quickly and easily. With wro4j, all I had to do was 1) add the JAR to WEB-INF/lib, 2) add a wro.xml file and define my groups and 3) configure the filter in web.xml. Then I simply changed the HTML to point to /wro/groupName.css and /wro/groupName.js.

With Jawr, (I believe) I would've had to 1) add it to Roller's build process and 2) write some specialized macros for Velocity to pull in the bundles. In short, adding Jawr didn't seem like a 10 minute process.

Posted by Matt Raible on November 13, 2009 at 04:32 AM MST #

Hi Matt, thanks for your response
With Jawr the steps are nearly the same as with WROJ4, although it is true that you'd need specialized macros for Velocity.

The actual steps to install Jawr are:
1) add the JAR to WEB-INF/lib,
2) add a file and define your bundles
3) configure the servlet(s) in web.xml
4) Change your tags (the missing bit that requires velocity macros)

At least, that's the standard way for configuring Jawr. What made you think otherwise? Maybe we need to improve our docs, so please tell.

As for Velocity support, it shouldn't take long for us to add it to Jawr. We already support JSF and GSP tags since tag rendering is already thought out as an pluggable component. In fact, maybe you could get these macros done rather quickly (though in excess of 10 minutes I guess...), if you followed the guide at this page (which also tells useful tips for integrating in e.g. appfuse).

However, given Velocity support is not a readily available feature I see why you'd have a more suitable option with WRO4J. Expect Velocity support soon though! :-)

Posted by Jordi Hernandez on November 13, 2009 at 05:56 AM MST #

We've used pack:tag on several projects: successfully; you can configure it to use different JS/CSS compression engines.

I wrote about integrating it w/JBoss here:

Posted by Andy Pemberton on November 15, 2009 at 08:21 PM MST #

Like Andy, i've been using pack:tag for a little over a year on various projects with great success. I've quite liked the way you define the bundle of files to combine / minify in the jsp itself although i'm quite interested in looking at these alternatives. I'd be very interested to see google's new closure compiler integrated into one of these engines as well - maybe next time I start a project or get the time i'll look into how feasible this might be.

Posted by Rob on November 18, 2009 at 08:22 PM MST #

This is really great. It makes it possible to write clean and modular JS/CSS and still have great performance.

Posted by Jafar Sadik on March 07, 2016 at 03:36 AM MST #

Post a Comment:
  • HTML Syntax: Allowed