Running IntelliJ 9 Public Preview Community Edition on Mac OSX

JetBrains just announced they are open sourcing IntelliJ in a community edition with a subset of features from their commercial product.

Having used Eclipse almost exclusively in my Java work, I was interested in trying it out and went to download the .dmg file. I unpacked everything and tried to run the poorly named Maia-IC-90.94.app

Nothing came up. Lame.

I dug into the package and executed idea.sh which prompted me that I need to set the environment variable IDEA_SDK or JDK_HOME.

Ah ha!

In my .bash_profile, I set

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
export IDEA_JDK=$JAVA_HOME

And ran idea.sh again and IntelliJ came up.

Picture 1

Running Maia-IC.90.94.app still doesn’t run the app but at least now I can play around with IntelliJ.

Running IntelliJ 9 Public Preview Community Edition on Mac OSX

Linode API for Java

I’ve been really happy with my recent move over to http://www.linode.com.  I was checking out their API and noticed there wasn’t any Java client.  I wanted a do a small pet project so I took a couple hours this weekend and wrote a Java client for the API.

The API leverages Apache HTTP Client and JSON.org Java libraries and is built using Maven.

The project source code can be found here.

If anyone runs into any problems with using it, please feel free to ping me!

Update: Linode was nice enough to update their API page with a reference to my project.

Linode API for Java

Google App Engine adds Java support (Review)

Last night Google announced Java support on Google App Engine.

After a bit of toying around, here are my findings.

The Eclipse plugin is pretty slick. Deploying and build is simple.

The dev server that you spin up locally looks to be jetty under the hood.

Objects intended for storage are JDO annotated and after compiling, you run the .class files through the DataNucleus Enhancer which adds additional metadata so Google can map it to BigTable. The Eclipse plugin automatically performs this step for you after compiling. The examples provide a bunch of ant macros to help facilitate building/deploying.

One issue that I had was that the project was building with Java 1.6 and I would get an error after compiling:

Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file

Even though they say they support Java 1.5 and 1.6, I guess this doesn’t work on the Java 1.6 for the Mac. Switching the build to 1.5 allows the DataNucleus Enhancer to run successfully.

Even though they are using JPA, some features have not yet been implemented or supported ( see http://code.google.com/appengine/docs/java/datastore/usingjpa.html#Unsupported_Features_of_JPA)

Overall, I like what I see so far and think this would be great for quick prototypes of web apps/services.

Going through the tutorial, my awesome Guestbook application has been created and deployed.

Google App Engine adds Java support (Review)

Checkboxes in Stripes and Spring MVC

When building dynamic web sites with lots of javascript UI components being created on the client, understanding how the web framework you’re using will process the request and what must be done to update fields accordingly is even more important.

Specifically, checkboxes have always been a pain to deal with. The gotcha with checkboxes are if a checkbox isn’t checked, the request doesn’t send the parameter so it requires some additional checks to detect that the user deselected something that was there to update the field accordingly. I’ve been playing around with the Stripes framework and ran into this issue.

With Stripes, you can render a checkbox using their JSP tag:

<stripes:checkbox checked="true" name="property1" value="yes"/>
<stripes:checkbox checked="true" name="property2" value="no"/>

When the “checked” value is equal to “value” value, Stripes will render the checkbox as checked. So with the code shown, two checkboxes will be shown with the first checked and the second unchecked.

If a user reverses this by unchecking the first, checking the second, and submit the form, the HTTP request will only see that property2=no. Before the form was submitted, “property1” had a value of “yes”. Now, “property1” won’t even appear in the request parameters, so we have to do special handling to check for the absent of the parameter to update “property1” to whatever value it should be when it is not checked.

In Spring MVC with form binding, checkboxes are dealt with a little differently. Using Spring MVC’s form JSP tag, you can do:

  <form:checkbox path="property1" value="yes"/>
  <form:checkbox path="property2" value="no"/>

Assuming your command bean is named “person”, this will generate the following HTML:

        <input name="person.property1" type="checkbox" value="yes"/>
        <input type="hidden" value="1" name="_person.property1"/>
        <input name="person.property2" type="checkbox" value="no"/>
        <input type="hidden" value="1" name="_person.property2"/>

As noted by the docs,

What you might not expect to see is the additional hidden field after each checkbox. When a checkbox in an HTML page is not checked, its value will not be sent to the server as part of the HTTP request parameters once the form is submitted, so we need a workaround for this quirk in HTML in order for Spring form data binding to work. The checkbox tag follows the existing Spring convention of including a hidden parameter prefixed by an underscore (“_”) for each checkbox. By doing this, you are effectively telling Spring that “the checkbox was visible in the form and I want my object to which the form data will be bound to reflect the state of the checkbox no matter what”.

Spring MVC also provides a “checkboxes” tag which allows you to render a list of checkbox boxes without having to wrap the “checkbox” tag around a JSTL forEach.

Hopefully, that gives you some insight into how to work with checkboxes in Stripes and Spring MVC.

Checkboxes in Stripes and Spring MVC