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.
Friday, October 29, 2010
Tuesday, October 5, 2010
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)Sunday, October 3, 2010
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.
====== 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.
Monday, September 27, 2010
Google Sidewiki entry by Andrew
I was looking for this to help me assemble my assignments for my AJAX course. I had lots of code and html files that I had to assemble into a PDF for turn in. This made it much easier!
in reference to: Automator Tip of the Week #3: Convert Word Documents to PDF | Mac Help from Maciverse (view on Google Sidewiki)Friday, September 24, 2010
FxBattle will be built by Gradle
One of the hold ups with FxBattle was JavaFx 1.3. When that was resolved, we'd forgotten how to build the system. It took a night at JavaOne to get it running again. We can build and run now using Fx 1.3 (which is WAY FASTER- YEAH!).
However, it's a big old hacky system and I don't like it. I used Maven, but lack of documentation, and severe rigidness were sufficient to make me want to abandon the technology. At JavaOne I learned about Gradle. It's a different kind of build toolkit.
I'm finding that I like it immensely. It is somewhat immature right now, but the activity surrounding it seems huge. The documentation is surprisingly complete for a product that isn't even version 1.0 yet. I've had some trouble getting plugins working in version 0.8. It required a bit of hacking and wasn't particularly strait forward. This said, 0.9 will have a much better plugin system (just drop a Jar into your system). There also appear to be plans for a plugin repository in the future so you can just ask for it by name.
I don't see a plugin for Gradle which builds JavaFx. If the plugin development documentation gets better, I may start such a plugin. At least, we'll have to be able to build JavaFx in FxBattle through Gradle.
However, it's a big old hacky system and I don't like it. I used Maven, but lack of documentation, and severe rigidness were sufficient to make me want to abandon the technology. At JavaOne I learned about Gradle. It's a different kind of build toolkit.
I'm finding that I like it immensely. It is somewhat immature right now, but the activity surrounding it seems huge. The documentation is surprisingly complete for a product that isn't even version 1.0 yet. I've had some trouble getting plugins working in version 0.8. It required a bit of hacking and wasn't particularly strait forward. This said, 0.9 will have a much better plugin system (just drop a Jar into your system). There also appear to be plans for a plugin repository in the future so you can just ask for it by name.
I don't see a plugin for Gradle which builds JavaFx. If the plugin development documentation gets better, I may start such a plugin. At least, we'll have to be able to build JavaFx in FxBattle through Gradle.
Tuesday, September 14, 2010
Learning AJAX
Turns out that you should know JSP before you start learning AJAX. Well, looks like I get to learn both together. Just started night school for a Masters in CS. I think it'll be interesting, but I have some trepidation about time constraints. It should help that APT is going to freeze soon so that I won't be under as much pressure to deliver the outstanding bug fixes/features.
Friday, July 2, 2010
Learning Groovy
Groovy looks like a cool thing to know. It looks like it's strictly better than Beanshell. It's a JVM language which is a superset of Java. I'm not planning on using any part of it except that it allows dynamic execution of java code. How cool! I'm expecting to author a scripting language in Groovy that will act as an controller for our application. It's been really easy to setup so far and I like it.
Subscribe to:
Posts (Atom)