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.

Congratulations on Retiring Dad!

Dad's New Rig Today is a very special day in my Dad's life. Today is his last day of work. Within the next hour, Joseph Edward Raible, Jr. will officially become retired and subsequently one of the happiest people I know. My dad has always had an interesting relationship with work. I've never met someone who hated working for The Man more, yet had such a strong work ethic.

Growing up in Montana, my dad always had the shittiest jobs. When I was a toddler, he used to walk several miles to work, often during the cruel Montana winters. As I got older, I remember him working as a carpenter, logger, trail crew specialist, firefighter, radio technician and even a programmer. The reason his jobs were so shitty is because he told us they were. I don't think he made over $5/hour until I was in the second grade.

He was able to turn his career around in impressive fashion in the early 90s. He'd always been a "computer guy" at the cabin. He even went to Graduate School for his Masters in Computer Science. When we moved to Oregon, he volunteered at my mom's new office as a Network Administrator. After 6 months, they hired him and he quickly moved up the ranks. I believe his current title is something fancy like Director of Wireless Communications. Over the last 19 years, he's worked for the BLM and done amazing things like setup radio networks in Honduras and Tanzania. He's turned into quite the world traveler.

The thing I remember the most is his perseverance. One winter when he couldn't find work, he built a barn. From scratch, mostly by himself.

The other thing I remember well is how much he complained about work. It was never the actual work that he complained about, it was the "stupid fuckin' idiots" that he had to work with (or for). This is the reason that this is such a special day. I can't help but think a huge weight is being lifted from his shoulders and he's going to much happier. Then again, you know how these things go - he might actually miss having people around to complain about.

One thing's for sure, I'm super pumped and happy for the guy. He plans on moving back to Montana for the summer to work on the New Cabin and it's likely I'll get to spend a lot more time with him in the coming years.

Congratulations and cheers to you Dad. You did it. I'm extremely proud of you today. :-D

Posted in General at Mar 31 2009, 04:46:47 PM MDT 6 Comments

New Office and New Bike

Back in January, I moved into a new office to work on my current project. The following week, my bike was stolen. The next day I ran to work and decided to do it for a couple months.

My current goal is to run until April 1st or until I lose 20 pounds, whichever comes first.

The next week, my co-worker's bike was stolen and I knew I had to stick with my goal. The significance of April 1st was that our office lease expires on April 1st and we were planning on moving to a new office. While our office is nice, it is a large one-room office with no windows. The previous office was quite a bit cooler, but also cost twice as much.

Raible Designs HQ 2009 A couple of weeks ago, we found a nice office near downtown. I signed a 1-year lease and moved in over the weekend. For folks in Denver, you might recognize the nice location.

I did my final run to work last Thursday, in the midst the Blizzard of 2009. Almost Whiteout While running to work was a great experiment and I enjoyed telling people I was doing it, it wasn't fun. I've been riding my bike to work for many years (first year was 1999). The one thing I've always enjoyed was the thrill of the ride in the morning. On a beautiful spring day, it's really a fantastic experience. It's easily been the best part of any job I've ever had.

New Trek FX 7.5 With the new office secured and the running mission completed, I walked over to my favorite bike shop and picked up a Trek FX 7.5 yesterday. To research and figure out which bike to buy, I asked my network on LinkedIn.

As luck would have it, my first ride to the new office was today and First Ride on New Trek we woke up to a morning snow storm. Even though the ride was cold and wet, I still had a blast. I've enjoyed riding since I traversed the hills on a BMX bike back in Montana. Getting back in the saddle today was simply awesome and I can't wait to ride again tomorrow, regardless of the weather. I know those nice spring days are just around the corner. :-D

Posted in General at Mar 30 2009, 11:51:39 PM MDT 3 Comments

Optimizing a GWT Application with Multiple EntryPoints

Building a GWT application is an easy way for Java Developers to write Ajax applications. However, it can be difficult to release a GWT application to production before it's finished. One of the most important things I've learned in Software Development is to get a new application into production as soon as possible. Not only does getting it from dev → qa → prod verify your process works, it also can do a lot to test the viability of the new application.

One of the biggest issues with GWT applications is size. The project I'm working on compiles Java to JavaScript and creates ~570K *.cache.html files (one for each modern browser). These files end up being around 180K gzipped. I believe this is an OK size for an entire application. However, if you're going to release early, release often with GWT, chances are you'll just want to release one feature at a time.

When the first feature was completed on my project, the *.cache.html files were around 300K. Rather than using branches to release to QA and UAT, bug fixes and new features were developed on trunk. Unfortunately, the QA and UAT process took several weeks longer than expected so by the time the feature was ready to release, the *.cache.html files had grown to around ~570K. The reason the file had grown so much was because it included all of the other features.

Earlier this week, while running to a dentist appointment, I thought of a solution to this problem. The basic idea was to optimize the compilation process so only the to-be-released feature was included. Even better, the solution didn't require more modularization. The results:

Before: *.cache.html -> 569K, gzipped 175K
After: *.cache.html -> 314K, gzipped 100K

According to my calculations, that's a 56% reduction in size. How did I do it?

  1. Created a new EntryPoint with only the to-be-released features imported.
  2. Created a new FeatureName.gwt.xml that references the new EntryPoint.
  3. Copied old (kitchen-sink) EntryPoint.html to FeatureName.html and changed the reference to the nocache.js file.
  4. Created a Maven profile that allows using -PFeatureName to build a FeatureName-only module.

One downside to doing things this way is it's possible to create a WAR that has the same name and different features. Surely the Maven Overlords would frown upon this. Since this is just a temporary solution to release features incrementally, I'm not too worried about it. A possible workaround is to create different WAR names when a feature's profile is activated. I believe the true "Maven way" would be to make the "kitchen sink" application into a JAR and have several WAR modules with the different EntryPoints. Seems a bit complicated to me.

Other than this Maven publishing issue, the only other issue I can foresee is keeping the two EntryPoints and HTML files in synch. Then again, the separate files allow a feature to be customized for the release and can be deleted when its no longer needed.

What do you think? Do you know of a better way to compile a GWT application so it only contains certain features?

Posted in Java at Mar 25 2009, 04:00:37 PM MDT 12 Comments

Modularizing GWT Applications with GWT-Maven

Last week, I spent some time modularizing the GWT application I'm working on. By modularizing, I mean splitting the code from one GWT module into a "core" and "webapp" module. The reason for doing this was so the "core" module could be used by another GWT application. Creating GWT Modules is fairly straightforward, but it wasn't as intuitive as expected when using the gwt-maven-plugin.

The hardest part of moving the code was figuring out how to run tests in the new "core" module. After getting it all working, it seems easy enough. Hopefully this post will make it easy for others. Here's the steps I'd recommend:

  1. Convert your GWT project into a multi-module project where you have a top-level pom.xml and two sub-modules (e.g. gwt-core and gwt-webapp).
  2. Do the normal single-to-multi-project Maven stuff like declaring the <parent> element in the modules and moving plugins/dependencies to the top-level pom.xml.
  3. Refactor your gwt-webapp project to push down all shared classes (and their tests) to gwt-core.
  4. In the gwt-core project, include *.xml and *.java in your JAR so GWT can extract/compile the source code when building gwt-webapp.
  5. In gwt-core/src/main/java, create a Core.gwt.xml that references the modules you'd like to use in all your applications. For example:
        <inherits name=""/>
        <inherits name=""/>
        <inherits name="com.extjs.gxt.ui.GXT"/>
        <inherits name="pl.rmalinowski.gwt2swf.GWT2SWF"/>
  6. Now the tricky part begins, mostly because of how the gwt-maven plugin currently works. In src/test/java, create a NoOpEntryPoint.gwt.xml that inherits your Core module and defines an EntryPoint.
        <inherits name=""/>
        <entry-point class=""/>
  7. Create a class in the same directory as NoOpEntryPoint.gwt.xml.
    public class NoOpEntryPoint implements EntryPoint {
        public void onModuleLoad() {
            // do nothing
  8. In any class that extends GWTTestCase (I usually create a parent class for all tests), reference the NoOpEntryPoint in the getModuleName() method.
        public String getModuleName() {
            return "";
  9. Lastly, in the gwt-maven plugin's configuration (in gwt-core/pom.xml), reference the NoOpEntryPoint in <compileTargets>, a non-existent file in <runTarget> and only the "test" goal in the executions.

The results of modularizing your application are beneficial (shared code) and detrimental (you have to mvn install gwt-core whenever you make changes in shared classes). If you know of a way to configure the gwt-maven plugin to read sources from both gwt-core and gwt-webapp in hosted mode, I'd love to hear about it.

Posted in Java at Mar 23 2009, 10:36:08 AM MDT 11 Comments

GXT's MVC Framework

For the past couple of months, I've been developing a GWT application using a mix of plain ol' GWT and GXT widgets. When I first started developing it, I didn't know how to best organize my code and separate the logic. The solution I came up with was to adopt some sort of MVC framework. Since I was already using GXT, I opted for GXT's lightweight MVC implementation.

As mentioned in Testing GWT Applications, GXT's MVC doesn't have much documentation. The best reference documentation seems to be Christian's Getting started with Ext-GWT: The Mail reference application.

Page Transitioning with Dispatcher
After working with GXT MVC for a couple months, I'm still not sure I fully understand how navigation and event dispatching works. The biggest point of confusion for me is how to best use GXT's Dispatcher class.

The problem with Dispatcher is it has a two methods that seem to do the same thing.

  • forwardEvent (4 variations)
  • dispatch (3 variations)

In addition to these methods in Dispatcher, there's two fireEvent methods in GXT's View class. According to my calculations, that means there's 9 different options for transitioning from one view to the next. Which one is best to use?

From what I've learned, I think it's best to use fireEvent in Views and forwardEvent in Controllers and other widgets. IMO, dispatcher should never be used except in your HistoryListener's implementation onHistoryChanged method. The important thing to realize about this method is it should only work if the View's Controller is registered for the event.

  protected void fireEvent(AppEvent event) {
    Controller c = controller;
    while (c != null) {
      if (c.canHandle(event)) {
      c = c.parent;

However, fireEvent seems to work even when the View's Controller isn't registered for that event. This is because onHistoryChanged gets called in the EntryPoint. For experienced GXT MVC users, does this navigation handling mesh with your findings?

The most important thing for navigation to work successfully is enabling History support. The next section talks about how to do this effectively.

Enabling History Support
To help explain things better, I created a simple GWT MVC Example application and used Maven to create an archetype with it. You can create a project from the archetype using the following command:

mvn archetype:create -DarchetypeGroupId=org.appfuse.archetypes \
-DarchetypeArtifactId=gwt-mvc -DarchetypeVersion=1.0-SNAPSHOT \ -DartifactId=myproject \

To enable history support in this application, I implemented HistoryListener in my EntryPoint ( and added the following logic to initialize:

// If the application starts with no history token, redirect to 'home' state
String initToken = History.getToken();
if (initToken.length() == 0) {

// Add history listener

// Now that we've setup our listener, fire the initial history state.

In this example, HistoryTokens is a class that contains all the URLs of the "views" in the application.

public class HistoryTokens {
    public static final String HOME = "home";
    public static final String CALENDAR = "calendar";
    public static final String NOTES = "notes";
    public static final String SEARCH = "search";

In order to make URLs like http://localhost:8080/#calendar go to the calendar view, the following logic exists in the onHistoryChanged method.

        Dispatcher dispatcher = Dispatcher.get();

        if (historyToken != null) {
            if (historyToken.equals(HistoryTokens.HOME)) {
            } else if (historyToken.equals(HistoryTokens.CALENDAR)) {
            } else if (historyToken.equals(HistoryTokens.NOTES)) {
            } else if (historyToken.equals(HistoryTokens.SEARCH)) {
            } else {
                GWT.log("HistoryToken '" + historyToken + "' not found!", null);

Controllers are registered in the EntryPoint as follows:

        final Dispatcher dispatcher = Dispatcher.get();
        dispatcher.addController(new CalendarController());
        dispatcher.addController(new HomeController());
        dispatcher.addController(new NotesController());
        dispatcher.addController(new SearchController());

Controllers respond to events they're registered for. This is done in their constructor:

    public CalendarController() {

In order for navigation to work, you have to create links with history tokens1. For example, here's a link from the HomeView class:

	Hyperlink notesLink = new Hyperlink("Notes", HistoryTokens.NOTES);
	notesLink.addClickListener(new ClickListener() {
	    public void onClick(Widget widget) {

You'll notice in this example, I'm using Dispatcher's fireEvent method. If I wanted to pass some data with your event, you'll need to use forwardEvent. Here's an example from CalendarView:

    Button submit = new Button("Submit");

    submit.addSelectionListener(new SelectionListener<ButtonEvent>() {
        public void componentSelected(ButtonEvent ce) {
            AppEvent<Date> event = 
                new AppEvent<Date>(AppEvents.GoHome, date.getValue(), HistoryTokens.HOME);

In this example, you could also use Dispatcher.dispatcher(), but I believe this will cause the transition to happen twice because the onHistoryChanged method gets called too. This doesn't matter for the most part, except when you start to use DispatcherListeners.

Hopefully this article has helped you understand how GXT's MVC framework works. I'm interested in learning how other GWT MVC frameworks work. If you've used one, I'd love to hear about your experience.

Friday Fun Test
Here's a test for those interested in digging into the GXT MVC example. There's a bug in this application that prevents something from happening. I'll buy a drink for the person that finds the bug and I'll buy two drinks for the person that comes up with a solution. ;-)

1. If you use the default constructor on Hyperlink and use setText(), make sure to call setTargetHistoryToken() too. If you don't, a blank history token will be used and # causes the browser to scroll to the top before a page transition happens.

Posted in Java at Mar 13 2009, 11:48:41 AM MDT 25 Comments

1st Hike of 2009

This past Sunday, the kids and I loaded up our camelbaks and headed out for a hike to the top of Dakota Ridge Trail. We parked in the Green Mountain parking lot next to C-470 and trekked up the west-side of the mountain.

Ready to go Hiking Jack Heading up Dakota Ridge

First of all, I was impressed with their enthusiasm. Granted, it was a beautiful Denver spring day, but still - you know how 4 and 6 year olds are. I'm not sure how far it was, but I'd guess somewhere between 1 and 2 miles. Abbie was gung-ho the entire way up, while Jack kept saying he was tired and wanted me to carry him. I never broke down, kept encouraging him and they both made it to the top without any issues.

While at the top, they did some exploring and Abbie gathered a whole backpack full of rocks for the trip down. By the time she was done filling it, it must've weighed around 20 pounds. Even though it was pretty darn heavy, she carried it all the way down - stopping every-so-often to empty a few rocks out. We weighed it when we got home and discovered it was 10 pounds. I was very impressed with her strength and perseverance.

Well done kids!

Jack on Dakota Ridge Collecting Rocks On the top

How old do kids have to be before you take them up a 14er? ;-)

Posted in General at Mar 09 2009, 10:28:20 PM MDT 4 Comments

Nexus is a kick-ass Repository Manager

I started my current gig at the end of last year. I've been enjoying the work and especially the project infrastructure we've been using. We're using the usual suspects: JIRA, Confluence, Hudson and Subversion. We're also using a couple new ones, namely sventon and Nexus. For building, we're using Maven and Ivy (as a Grails plugin).

Nexus I'm writing this post to talk about Nexus and how much I've enjoyed using it. I like Nexus for two reasons: it's aesthetically pleasing and it's well-documented. Another reason I really dig it is because I haven't had to touch it since I first configured it. Software that just keeps on humming is always fun to work with.

Initially, I remember having some issues setting up repositories. I also remember solving them after learning how groups work.

In addition to on-the-job, I've started to use Nexus more and more in my open source life. With the help of Jason van Zyl, I recently moved AppFuse's repository to Sonatype's I also noticed there's a Nexus instance for Apache projects. If that's not enough, you can get Nexus Pro free if you're an open source project.

Personally, the open source version of Nexus seems good enough for me. While the Staging Suite looks nice, I think it's possible to do a lot of similar things with good communication. After all, it's not going to free you from having to wrestle with the maven-release-plugin.

Next week, I'm helping to polish and document our entire release process (from dev → qa → production). If you have any advice on how to best perform releases with Maven, Grails and/or Nexus, I'd love to hear about it. My goal is extreme efficiency so releases can be done very quickly and with minimal effort.

Posted in Java at Mar 05 2009, 11:59:02 PM MST 13 Comments

GWT and AppFuse

Someone recently sent me the following e-mail asking about GWT integration in AppFuse.

I see from your blog that you're spending some time with GWT at the moment. What's your plan, are you going to integrate GWT as another UI Option for AppFuse?

The reason I'm asking is that I actually checked out all of the AppFuse code from the svn repository yesterday, with the intention of starting off adding some GWT stuff in there. My intention was to start by getting a basic Maven archetype together for GWT as an AppFuse UI.

However, if you're planning on doing this yourself in the near future, then there's no point in me starting doing it, I'd have to learn how to write archetype's for a start (not that it looks too difficult) but you'd obviously do it much quicker.

Being a good open-source developer, I moved the discussion to the developer mailing list and replied there:

It's likely I'll create a version of AppFuse Light with GWT, but I doubt I'll do it in the near future. I hope to release AppFuse 2.1 first (which will include "light" archetypes). I wouldn't get your hopes up in waiting for me to do the work. However, I'd be happy to assist you in doing it. AppFuse Light is now modular and uses the AppFuse backend.

Here's how I believe GWT should be integrated:

  1. Create an appfuse-ws archetype that serves up RESTful services (
  2. Create an appfuse-gwt archetype that consumes those services. This archetype would contain a proxy servlet that allows #1 to be on a separate host/port.

In addition to #1, I hope to convert the Struts 2 and Spring MVC archetypes to use those frameworks' REST support.

For #2, we could use SmartGWT or GXT. SmartGWT might be better since Sanjiv is a committer on this project. ;-)

I know I've been slacking on AppFuse development, but it is ski season and running to work seems to drain my late-night coding ambitions. With that being said, I'm committed to getting AppFuse 2.1 released by JavaOne (hopefully sooner). I figure it's a good week's worth of work and I'll probably have to do it late at night to find the time. That's OK though, I usually really start to enjoy it once I get into it.

Posted in Java at Mar 04 2009, 10:50:26 PM MST 5 Comments

New 15" MacBook Pro with SSD

Just over a month ago, I reduced my computing machinery from 3 to 1. Since I was running to work, this quickly presented a problem of how to get my laptop to/from the office. I decided to go for the "no home computer" about half the time and it was a fairly pleasant experience. It's hard to stay up late and hack away on open source when all you have is an iPhone.

To be perfectly honest, I only made it about 2 weeks before I ordered a new laptop, but I cancelled the order shortly after. Last weekend, I re-ordered and my new 15" MacBook Pro arrived this past weekend. Here's the specs:

  • Processor: 2.8 GHz Intel Core 2 Duo
  • Memory: 4 GB 1067 MHz DDR3

I also chose the solid-state drive (SSD) because I'd heard it's faster. I did some rough performance comparisons against my old laptop (a 2-year-old 17" MacBook Pro) and found it's quite a bit faster.

For these tests, the computers have exactly the same software and OS (I restored my new MBP from my old one). For the tests below, I used Java version "1.5.0_16" and had JAVA_OPTS set to the following:

-Xms512M -Xmx768M -XX:PermSize=256m -XX:MaxPermSize=512m -Djava.awt.headless=true -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+UseConcMarkSweepGC. 
ComputerOperationTime (mm:ss)
New MacBook Pro with OS X 10.5.6 (2.8 GHz, 4 GB RAM)appfuse: mvn install3:23
cp -r appfuse appfuse20:28
gwt-project: mvn install1:24
Old MacBook Pro with OS X 10.5.6 (2.33 GHz, 3 GB RAM)appfuse: mvn install4:11
cp -r appfuse appfuse20:56
gwt-project: mvn install2:21

From these numbers, you can see that it's around 20% faster for building AppFuse (2.1-SNAPSHOT) and almost twice as fast at copying files and building the GWT project I'm working on. Needless to say, I'm impressed and pleased with my purchase.

Update: New MacBook Pros came out today with a faster CPU (2.93 GHz) and 256 GB SSD. I was able to call Apple and get a full refund on mine. Thanks Apple!

Posted in Mac OS X at Mar 02 2009, 07:24:28 AM MST 14 Comments