Gradle, my new build tool?

Last week, i had the pleasure of attending the JavaEdge conference. The keynote speaker was Ted Neward, and you could read his thoughts about the conference here. I enjoyed his lecture very much whose theme was that new programming languages in the VM is the future and we should all get used to it and get comfortable with it.

One of the sessions that i attended was “Your Next Successful Build”, given by Baruch Sadogursky, who used a slick tool instead of Powerpoint for his presentation, though it was a bit dizzying. I was happy that for the first time, i heard someone say some of my heretical thoughts – that while Maven has a lot of positive, it has many warts, mostly for the reasons of lack of documentation as well as dependency management. As a side note, i  was amazed to see that statistics show that 44% of companies are using Maven, which probably means they are spending countless hours debugging build issues!  It was also refreshing to hear him mention the pros of Ant as well as something he wants to be able to continue to use in his new build environment. But the most exciting part was to hear from Baruch that there is a tool out there that answers the call and it is Gradle. On the one hand, we like the standardization of the file layout of maven, but Gradle adds in better documentation (200 pages!!!), and the ability to use a scripting language, Groovy, which also means you automatically have full access to Ant via Groovy. And of course, he says that dependency management has been fixed as compared to Maven 2. I am hoping to try it out in my next project.

Why did Hibernate do that?!

As i have mentioned in the past, i am not a fan of Hibernate and other ORM tools that generate the SQL for me. This week i have yet another reason for not being willing to consider changing my opinion.

Unbeknownst to me, in our Hibernate application when we were using an “update” to update the one or two columns we change during the regular running of our application, we discovered that actually the update was updating all fields as well as cascading to additional tables joined to this object, which included a CLOB that was getting and update called on it and causing a lot of overhead.

After being warned by our DBA’s to fix ASAP, our next step was to reproduce the problem in our environment so we quickly turned on the “hibernate.show_sql” property to see our SQL. And before we even got to the issue we were looking to solve, we discovered another perplexing Hibernate-ism. We found that when we were doing an initial load or find by id, we were seeing an update happening to the record at the same time as the find/load!

After some fishing around the internet, we understood why this was happening. It was because one of out getters was changing the value from null to something more meaningful, as we see here. When we altered the code to not have this happen, then that update was prevented.

Now onto the problem we were meant to deal with (isn’t always the case that this happens!). After not seeing the results we were hoping for through setting some of the parameters mentioned in various forums (dynamic-update and select-before-update) in an attempt to have our Hibernate “update” not cascade unnecessarily through all the objects and update them all, we settled on a very iBatis like solution. We created the update ourselves so that we know what we are updating, i.e:

String hql = "update myTable set field1 = :field1 where id = :id";
Session session = SessionFactoryUtils.getSession(getSessionFactory(), false);
query = session.createQuery(hql);
query.setString("field1", myObj.getField1());
query.setLong("id",myObj.getId());
query.executeUpdate();

Of course, once you are doing this, you have lost the “advantage” of Hibernate.

Java Web Start – putting my application out there

I recently decided to write a small Java Web Start application using Groovy and Swingbuilder (and HttpBuilder). As i had no experience with Java Web Start, there was a bit of a learning curve. I knew that i would need signed jars in order for my application to be able to write to the local file system. However, a true signing certificate can be very expensive so i realized i would best serve my needs with a self signed certificate that i would keep renewing every 6 months. Using Ant, i have been able to have my app easily deployed with new signed jars.

It is important to mention that there is one simple solution that I did not use for my application, which is to use Griffon, as it takes care of all this stuff behind the scenes for you. However, since I had a simple application and had begun before i knew about it, I decided not to go this route and do it myself, which also ensures i have a better understanding of what is going on. Griffon will still be useful to you for reference. I especially found it useful to look over a sample jnlp file, the file used to list dependencies and configuration information

For signing the jars, i created a self signed certificate. However, every 6 months, i need to renew this certificate, which is pretty straightforward:

keytool -selfcert -keystore keystore -alias myAlias

After re-creating the certificate, i use ANT to sign and deploy. As Ant has a built in task for this, it is trivial:

   1: <target name="signJars" description="sign the jars" depends="makeJar">

   2:         <mkdir dir="signed"/>

   3:         <mkdir dir="signed/lib"/>        

   4:         <signjar destDir="signed"

   5:                  alias="mastertorah" keystore="keystore"

   6:                  storepass="changeit"

   7:                  keypass="mastertorah"

   8:                  >

   9:             <path>

  10:                 <fileset dir="dist" includes="**/*.jar"/>

  11:             </path>            

  12:         </signjar>

  13:         <signjar destDir="signed"

  14:                          alias="mastertorah" keystore="keystore"

  15:                          storepass="changeit"

  16:                          keypass="mastertorah"

  17:                          >

  18:                     <path>

  19:                         <fileset dir="dist" includes="**/*.jar"/>

  20:                     </path>            

  21:         </signjar>

  22:     </target>

In case you are wondering, line 3 above creates a second folder since my signed dependency jars sit separately from the main code; i just left this repeated signing command out of the snippet above.

As you see, line 4 uses the built in ant task signjar and it references my keystore. So, now i have a simple build process to easily redeploy my application.

For users reporting problems after deployment, one thing i have found helpful is to tell them to enable debugging, which is set in the control panel on Windows machines (in the java option there). This way they can send you a log of what went wrong.

I am left with one question. Why should i use SwingBuilder when i can drag and drop widgets using an IDE and get the format of my layout more simply.