Programming Tool Reviews

I'm a tools guy. With the right tools, hard jobs become easy. Finding good tools can be difficult and as time passes, the best tools for a given job change. I'll be writing posts here to document the tools I find and my experiences with them.

A few quick lessons about Gradle, Jaxb, and XML

It surprising how much certain kinds of little roadblocks can slow you down. So I thought I'd mention my Gradle/Jaxb/XML woes of late in hopes they'd be helpful.

First, it appears as though the element name in XSD files is case sensitive in some tools and not in others. This means that when I took an (apparently functional) XSD and tried to run it through ant xjc (using gradle) it broke.

Java has a limit to the length of a qualified classname. According to stack overflow it is 64k. I never imagined I'd need to know that little factoid. But it turns out that one of my schemas has such a deep definition of types, that it exceeds this limit. The error warning isn't especially helpful.

Finally, I needed a feature in the jaxb plugin that wasn't available. So I implemented it. GitHub and the open ethic is amazing. It wasn't long ago when fixing adding a feature to a project on a whim would have been a serious undertaking. Instead, it was a pleasure to get my hands dirty and improve a project that had improved my project. That's the best kind of paybacks!

Gradle Sonar source compatibility

I'm slowly migrating a large project to Gradle. One of the major selling points is the Sonar plugin. I switched a module to Gradle and ran the 'gradle sonar' command. I got a screen full of exceptions that looked like this:

Fail to execute PMD. Following file is ignored:

/Users/spina/Code/apt/StagingGround/Utilities/src/main/java/gov/nasa/gsfc/util/VersionChecker.java
net.sourceforge.pmd.ast.ParseException: Can't use annotations when running in JDK 1.4 mode!
at net.sourceforge.pmd.ast.JavaParser.checkForBadAnnotationUsage(JavaParser.java:32)
at net.sourceforge.pmd.ast.JavaParser.MarkerAnnotation(JavaParser.java:5353)
at net.sourceforge.pmd.ast.JavaParser.Annotation(JavaParser.java:5272)
at net.sourceforge.pmd.ast.JavaParser.Modifiers(JavaParser.java:347)

I was building for Java 7. I did the obvious google searches and didn't find an answer. A bit more work and I found the solution here. Basically, I needed to add the following to my build.gradle file:

sonar {
// Tell sonar where the cobertura codecoverage reports are and what version of java to use.
projectProperties([ 'sonar.java.source': '1.6', 'sonar.dynamicAnalysis': 'reuseReports', 'sonar.cobertura.reportPath': 'build/reports/cobertura/coverage.xml' ])
}

The important bit was this: 'sonar.java.source': '1.6'. Hope this helps someone =).

What can I do?

I want to have a list of the skills that I have. This is to help me track my growth and may help me identify solutions to problems that I face in the future. Hopefully I'll update this occasionally...

1) Java - 3+ years professional experience as of 2011.
2) CVS - Version control.
3) Mercurial - Better Version Control.
4) Groovy - Writing a 'Domain Language' for external users (still not sure how successful I was)
5) Groovy Scripting - Shell scripting using a Java Dialect
6) JavaFx - A rendering language for Java. Needs better tooling.
7) Html - Through Notepad and WYSIWYG editors
8) Ajax - 1 graduate level class where I learned how it works.
9) Eclipse - A good IDE
10) Omnigraffle - A good diagram creation tool
11) Cosi - a listening infrastructure (developed by STScI).
12) Bugzilla - a bug tracking system.
13) Mylyn - a task management tool in Eclipse.
14) ant - build system
15) maven - better build system
16) gradle - even better build system
17) Sonar - build analysis
18) cobertura - code coverage analysis
19) jUnit - unit testing of Java and Groovy code
20) Objective c - initial implementation of an iPad app.
21) SVN - better than CVS

Announcing Gradle-Plugin-JavaFx! JavaFx built by Gradle.

I complained earlier about how JavaFx is missing some really critical tooling. I mentioned debug support, and build support. In particular I was wishing that there was a JavaFx plugin in Gradle.

Because it was lacking and I really wanted FxBattle to build using Gradle. I decided to make such a plugin. Well, this is the official release of Gradle-Plugin-JavaFx version 0.1.0. I know, the name just rolls off your tongue.

It's an open source project that exists only to enable the FxBattle build. Still, others may find it useful. If they do, I'd love to hear from them. Keep up the great work Gradle developers. I love your product and am hoping to use it more widely soon.

Why I love OkGo

This is a beautiful video. Their use of vivid color and clever production combines with their mellow, trance-like music to give a really excellent and somewhat trippy experience.

in reference to: YouTube - OK Go - End Love - Official Video (view on Google Sidewiki)

What do I want to see developed for JavaFx?

JavaFx is a decent language for coding a User Interface. The interface for FxBattle would have been a bear to write in Java. Other languages might be easier than JavaFx, but I don't know of any that run on the JVM.

====== Performance Debug Tools ======

When I started work on the FxBattle GUI, I discovered that there was little support for Eclipse (my preferred IDE) so I worked on it using NetBeans. This was fine until I managed to get NetBeans into some strange state where I couldn't really build the project. Not Good. A bit later, I discovered a terrible performance issue in the code.

I spent hours trying to track down the problem. I looked online for 'best practices' for JavaFx. What I found was advise like 'don't use too many bindings', 'make unused components invisible', and others. At JavaOne this year, I went to a talk on performance tricks. They gave similar advise.

The problem with this kind of advise is that they are asking you to hunt through your entire code base and do guess-and-check debugging. You're suppose to find a binding, ask the question 'Is this the problem binding?' Then you're supposed to find some way to implement your logic without bindings and see if it's better.

Imagine debugging performance in an enterprise application like this. Our database updates are taking too long... let's look through all our DB queries and change them one at a time to see if the process gets faster. Of course that's out of the question. Instead we use profiling software to help us find the performance problem.

I did use YourKit to profile FxBattle. It told me that most of the processing was spent redrawing the GUI. This was no surprise. The problem was, YourKit couldn't tell me what code was queuing up the redraws that were taking up the time. So I had to fall back to the guess-and-check debug system. This completely killed my progress. I was guessing that the problem was in the JavaFx core anyway, so I just waited for JavaFx 1.3. When it was released the performance of FxBattle was greatly improved.

====== Build Tools ======

Another reason I was working on FxBattle was to learn about build systems. The build for FxBattle is somewhat complex. Lots of subsystems, some of which are JavaFx, some use Protocol Buffers, some are Java, some are Clojure.

The first build system for FxBattle was Maven. I find I liked it better than I like Ant. It gives you more features in fewer lines of build logic. However, trying to get it to do anything it isn't already good at is really tough. There were no tools to build JavaFx, Clojure, or Protocol Buffers. Getting a sensible build put together was a real bear.

Given that Maven is a very popular build system, why wouldn't there be a plugin to build JavaFx already available? On top of that, I had Java Code which tried to invoke JavaFx code. Doing this required the JavaFx Runtime Jars on the classpath. So I should be able to specify a dependency in my POM that makes those Jars available. Nope, can't do that. The Jars aren't allowed in the Maven Central Repo. Why? Doesn't SUN (now Oracle) want people to develop JavaFx apps? Doing that means we have to be able to access the Jars during our build process.

At JavaOne this year, I decided to try rewriting the build to use a new build technology called Gradle. I'm nearing completion of this task. I really like Gradle.
I was surprised to find that there is already a plugin for Clojure and Protocol Buffers. Great! That makes the build much simpler. Though it did take a while for me to figure out how to hook them all up.

Okay, got the back end compiling, now it's time to compile the front end. Where is the JavaFx plugin for Gradle? There isn't one? There is a lot of hype around JavaFx, but an up-and-coming build system doesn't already have a plugin to compile it?

So, I wrote a plugin for Gradle that compiles JavaFx. It is based on Clojuresque and appears to do the job for my use case. I will probably publish it once I hear back from a few people that there isn't already a tool that does this job.

===== Summary =====

We need to be able to debug JavaFx performance.

We need to be able to build JavaFx in all the popular build systems.

Better Controls, CSS, and other such features aren't useful if we can't do the above.