blog.pursuit.be

BeJUG Distributed Versioning Tools in practice

noreply@blogger.com (Jo Voordeckers) — Sun, 24 Oct 2010 14:20:00 +0000

Last week Louis Jacomet and myself presented Distributed Version Tools in practice at BeJUG, we talked about the differences between the classic centralized versioning systems (CVS, SVN, ...) versus the modern distributed ones, next we compared GIT and Mercurial feature-wise and discussed new development workflows that DVCSes bring to the table.

We were lucky to have a very vocal audience, they've asked many interesting questions and gave great feedback. I was impressed by the number of people already experimenting with or wanting to move to GIT or Mercurial from SVN, clearly the dominant versioning system in used by the attendees. Someone wondered if in a team GIT and HG could be used together, while we didn't have an answer at the time, I can now confirm that a Mercurial extension to talk to GIT exists: http://hg-git.github.com/

We hope you all had an interesting evening, if you're looking for some reference material or couldn't attend the session, here are the slides:

Distributed Versioning Tools, BeJUG 2010

View more presentations from pursuit.

Make JavaFX applets smooth on Firefox for Mac

noreply@blogger.com (Jo Voordeckers) — Tue, 08 Jun 2010 20:11:00 +0000

Lately when I was browsing websites with JavaFX applets I noticed the Java plugin would either not work, load slowly, crash or flicker when scrolling the page. This wasn't the case on Safari, so I looked at the about:plugins URL which lists the currently installed plugins in Firefox.

I noticed 2 unknown plugins to me called MRJPlugin and Java Embedding Plugin, a plugin that's apparently shipped with every Firefox on Mac OSX. Basically this plugin allows to use the latest Java version in the browser. Since Java 6 update 10 with it's Java Applet Plugin v2 is available for Mac OSX Snow Leopard, it's actually not necessary to have the J.E.P. plugin enabled. In fact Firefox prefers this plugin over the official Sun Java Applet Plugin v2 wich offers improved load times, browser integration, stability, etc.

After I removed both plugins, Firefox was loading applets incredibly fast, near Flash load time performance. The applets don't flicker anymore when scrolling and so far haven't crashed on me.

To remove the unnecessary plugins you should remove both the files MRJPlugin.plugin and JavaEmbeddingPlugin.bundle from /Applications/Firefox.app/Contents/MacOS/Plugins .
To open the Firefox.app bundle in Finder you need to Ctrl+Click and choose Show Package Contents.

I hope this improves your JavaFX experience...

JSmooth Windows Service with custom JRE

noreply@blogger.com (Jo Voordeckers) — Tue, 09 Feb 2010 20:21:00 +0000

For a customer I needed a solution to launch a standalone Java application as a Windows Service. After evaluating a number of solutions I ended up with JSmooth 0.9.9-7 http://jsmooth.sourceforge.net/ a very nice open source product with nice GUI to guide you through the process.

Because the product of my customer depends on a specific JVM version we decided to bundle our JVM version with the product. JSmooth supports bundling a custom JVM, however when running as a windows service it ignores this setting. It's been a while since the original author responded to forum messages or released a new version, so I decided to jump in the C++ code. I'm nowhere near a C++ expert, but managed to create a simple workaround.

My bugfix (source + skeleton binary) can be downloaded here.

Just drop the winservice.exe file in your JSmooth installation under /skeletons/winservice-wrapper/ and recompile your service EXE. The service logfile should now be populated with messages indicating it's attempting to run your bundled VM and so on.

Enjoy!

Video in Java, no more JMF please, use JavaFX!

noreply@blogger.com (Jo Voordeckers) — Thu, 20 Aug 2009 18:49:00 +0000

I often get email from people asking me to help them with playing video in Java using JMF & FOBS, probably because of my post from last year: playing-flash-video-flv-with-java

The reason why I'm writing this is to make it clear to people that time has moved on since last year, and the long awaited Java Media Components framework which was annouced a few years ago has finally hit the shelves as the media playing capability built into JavaFX. So rest assured, you don't have to hack your way around JMF to integrate FFMPEG to play all your movies.

Just follow this link to the JavaFX samples website, there are plenty of better ways to play video in Java than a year ago. But you'd have to use JavaFX for that, don't worry JavaFX is simple and runs under Java so it integrates well with a regular Java app/applet.

Eclipse XML DetailFormatter

noreply@blogger.com (Jo Voordeckers) — Thu, 20 Aug 2009 18:34:00 +0000

Having had to work with XML a lot for a current project I was tired of drilling down the DOM objects in Eclipse's debugger so I went looking on the net for an Eclipse debug detail formatter and found one here:

I do had to remove a few lines to get it to work so here is my version, enjoy formatted XML tags from a DOM tree:

if (this == null) return null;

javax.xml.transform.TransformerFactory tf = javax.xml.transform.TransformerFactory.newInstance(); 

javax.xml.transform.Transformer transformer = tf.newTransformer();

transformer.setOutputProperty( javax.xml.transform.OutputKeys.METHOD, "xml");
transformer.setOutputProperty(javax.xml.transform.OutputKeys.INDENT,"yes");
transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount", "3" );


javax.xml.transform.dom.DOMSource source = new javax.xml.transform.dom.DOMSource(this);
if (source == null) return "Corrupted XML document: " + this.toString();

java.io.StringWriter os = new java.io.StringWriter();
javax.xml.transform.stream.StreamResult result = new javax.xml.transform.stream.StreamResult(os);
transformer.transform(source,result);

return os.toString ();

Devoxx Blended

noreply@blogger.com (Jo Voordeckers) — Wed, 17 Jun 2009 00:06:00 +0000

Since I'm member of the steering committe for the Devoxx 2009 conference it's my pleasure to inform you guys on what's comming...

First of all this year's Devoxx is in NOVEMBER, yes 1 month earlier, from the 16th to the 20th, again at the excellent venue: Metropolis Antwerp.

So far following speakers have confirmed:

Chris Richardson - Cloud Expert
John M Willis - Cloud Expert
Antonio Goncalves - JEE6 Author/Expert
Erik Hatcher - Lucene in Action Author
Emmanuel Bernard - Hibernate Search Founder/Author
Tom Bayens - jBPM Founder
Michael Kay - Java & XML Expert
Nicolai Josuttis - SOA Expert
Martijn Dashorst - Wicket Expert
Christophe Hermans - Spring ActionScript Founder
Prof. Eric Steegmans - Generics Expert
Holly Cummins - JVM Expert
Kirk Pepperdine - Performance Geek
Brian Goetz - Concurrency Lover
The JavaPosse - Podcast Experts :)
Howard Lewis Ship - Tapestry Founder
Paul Sandoz - JAX-RS Spec. Lead
The JavaFX Team - RIA Lovers
Bill Venners - Scala Expert
Romain Guy - Android Expert
Pierre Bonnet - Master in Data Management
Stephen Chin - co-author PRO JavaFX
Jean-Francois Arcand - Comet Expert

For people interested in doing a session at Devoxx we have openend the Call For Papers application for BOF's Quickies and Tools in Action: CFP (firefox only)

Hope to see you there!
www.devoxx.com

JavaFX, Flex and Silverlight are looking at the wrong enemy

noreply@blogger.com (Jo Voordeckers) — Tue, 16 Jun 2009 23:42:00 +0000

HTML and JavaScript were never seen as a real competitor in the RIA space given it's current limitations, but with the new featureset for HTML5: canvas (2D drawing), sockets (P2P communication), multithreading (background processing), audio/video, local storage... it might very well become the RIA platform of choice given today's huge developer base.
HTML5 won't be released for a couple more years, but Google and Apple are betting heavily on it so ~~Sun~~Oracle, Adobe and MS better keep an eye on it as well.
Link: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9134422

Wicket, Java web development makes sense again

noreply@blogger.com (Jo Voordeckers) — Sat, 13 Jun 2009 23:45:00 +0000

I've been meaning to write about my experiences with Apache Wicket after having it used extensively for my latest project.

So for this project we needed to write a web app with as few screens as possible, preferably a single document interface, keeping it very simple for the end user. The main target audience was the accountancy department, so it had to be keyboard driven. On top of that coming from an MS Access app, the users were expecting autocompletion and immediate validation-feedback.

Given these facts as a Java developer I was immediately thinking: Swing or Flex. No JavaFX still wasn't released at the time we started prototyping.
Unfortunately our client was unwilling to start with a new client technology involving browser plugins and the possible sideeffects of this on the already overworked helpdesk.

So on we went looking for the best matching web technology...

SpringMVC - the current standard web technology at that client. Although not a terrible web framework, the single document interface requirement, doesn't quite fit the SpringMVC Action based model. Secondly there aren't any AJAX components, unless you'd integrate third party JS libraries, something we wanted to avoid as much as possible.
JSF - being the new Java web standard for a while now has gained quite some traction on the job market. Being component based was one of the main reasons why we considered JSF, but with all the complexities that JSF development brings and all extra frameworks built around it like Facelets, RichFaces, Seam and even Spring to getting JSF to be productive and developer friendly didn't reassured my team we could deliver an approriate solution in time. Unfortunately we didn't have experience with JSF and from the experiences on the web we were quite sceptical.
GWT - Having used GWT for a proof of concept at a past client I was well aware of it's capabilities, but also it's weaknesses. GWT has undergone some major changes since it was released a few years ago. With that a lot of component libraries built around it have come and gone as well. Although in the early days the standard GWT components were pretty basic, the recent 1.6 release shows a big improvement in this area. So today it might have been a valid solution for our problem, but at the time of the project we were still facing the questionable components problem. Because GWT also involves a different development strategy and still has a poor Maven integration (also a standard at the client) we chose to go with option nr 4.
Wicket - a component based web framework that has been around since 2004 and since long has most of the features JSF 2.0 will maybe have by the end of this year. Given the history of the project, the many positive experiences mentioned in blogs and a team with 2 experienced Swing developers made us decide to go with Wicket.

So what makes Wicket so great.

Component based - a lot of the UI in our app could be disected into reusable components, really made our life easier in the long run.
Swing like - event listener and form composition approach used by Wicket is very similar to how you'd compose your UI in Swing. It's not very surprising given the founders of Wicket were Swing developers in a past life. So was 60% of our team.
XHTML templates - No messing around with JSPs and taglibs. Just plain old annotated HTML templates to describe your layout and components and then accompanying Java classes to define the behavior of your UI. This allowed for some very flexible components, processing and user-feedback.
Authentication / Authorization - support for plugging in your own authentication and authorization strategy at the component construction and rendering level. This allowed us to have @annotation-based declarative role-based authorization in our UIs.
AJAX framework - AJAX has been built into the core of Wicket, supporting AJAX events and behaviors and tight integration in the rendering lifecycle allowing the developer to think about the real business issue at hand, Wicket takes care of the rest.
Form Validation - form and component level validation is built into the core of Wicket and available as part of the lifecycle, even integrated with AJAX behaviors and partial rendering so you don't have to worry about that as a developer.
Binding - Forms and datatables have strong support for binding to your POJO's or models, based on reflection. You can even go several object hierarchies deep. This also works on the datatable with out of the box sorting and filtering based on such nested paths.
Statefull - the pages and components you define contain their state as member variables, so you don't have to mess with the HTTPSession, Wicket takes care of this as well.

Having developed for the web in JSP scriptlets/Servlets/Taglibs, Struts and SpringMVC always seemed like too much effort for what you get in return. It's also very confusing what is to happen next, every time I switch between one of those technologies I have to grab the manual again to understand the lifecycle. In Wicket it's straightforward, you instanciate your page class and add components to it, who have listeners and behaviors that you implement. These callback methods get called on the subsequent events... plain and simple!

Working with Wicket has been a pleasure, we started off with just building our prototype screens with XHTML and a little bit of Wicket magic to bring them to life. We soon realized that we could continue to build upon that prototype without having to rewrite all our screens in JSPs like we would have in the other technologies. Our client was very pleased with the non-static prototype and the fact that we didn't had to redo the screens for the real app, this is usually where it goes wrong when developers have to work with a webdesigner for the UI.
We were able to advance so quickly and managed to build some reusable components that can be packaged as JARs to be included in new applications, giving them a head-start.
For a small team without knowledge of the framework it took us just a few days to grasp the basic concepts and worked our way through the rest while working out the different parts of the application, it's just so straightforward and there is a great sample

Although Wicket is an excellent approach to web development in Java, there are a few things you should know...
As you are building a lot of view-logic in your Java code, with a lot of listeners and inner classes for callbacks etc, you really need to think 'components'.
All too often you start the next screen by copy-pasting from the last one. When if you think about it you realize it has about 50% of the same logic, which you should extract from both screens into an abstract component. If you fail to do this you get a messy codebase with a lot of code duplication and each developer tends to have it's own style so it can get messy if you don't work together and refactor in time.
But if you do this like we did, we ended up with a few handy base classes like AbstractFormTablePanel that we needed to give a few parameters and in about 20 lines of code we had a new master-detail CRUD screen for a new entity, with complete sorting, filtering and validation.

Another weak point is that although Wicket has AJAX built-in the core framework that handles JavaScript events and partial page refreshes perfectly a lot of the AJAX components (datepicker, tree, ...) are third party (wicket-extensions project for example) and they are not of the same quality as the core framework. We noticed some JavaScript compatibility issues with some browsers, mostely IE as you would expect. Unfortunately that was our target browser, as is the case in most large organizations.This was also because the Wicket team focussed more on getting Wicket 1.4 out of the door instead of fixing bugs in the old stable branch. Later we noticed that a 1.3.6 version had been silently released where some of our issues were addressed. At least there is still an active community supporting Wicket after so many years and that for a relatively small userbase. On a sidenote Wicket is still slowly gaining job-marketshare:

*note: GWT is 'off the charts' with about 175% growth... worth another look!

All in all I would definately choose Wicket again, it just makes sense and I've never had more fun developing for the web in Java!

Safari 4 == Safari 4x crash a day?

noreply@blogger.com (Jo Voordeckers) — Sat, 13 Jun 2009 16:21:00 +0000

I've been using Safari 4 beta for a couple of weeks ever since I found out it supported Apple's Java 6 'update 10' developer preview. As a JavaFX developer this has been an important improvement we've been waiting for since last year's JavaOne.

Since I'm mostely a Firefox user for all it's great plugins, I wasn't thinking about switching to another browser anytime soon. But after using Safari 4 beta for a while I was pleased with the speed, stability and CPU & MEM consumption, the latter is an area where Firefox has some huge issues.

So since a few weeks I've ditched Firefox and converted to Safari, and it has been great... until yesterday when Safari 4 has been updated to the final version. It has already crashed 4 times today, while just browsing GMail, blogs, etc... Safari 4 beta never crashed...

JavaOne 2009

noreply@blogger.com (Jo Voordeckers) — Wed, 10 Jun 2009 03:02:00 +0000

Last week I attended JavaOne 2009, this time only as attendee, so no stressy last minute demo and slide editing. Like last year it was awesome, having all the people from the Java community in one place is just amazing, especially the hallway conversations and afterparties are my favorite part of the conference.

As expected JavaFX was big news again, with finally the unveiling of the "designer tool", Tor Norbye did a few entertaining demos of this very promising tool. Next to that it was impressive to finally see JavaFX running on a few mobile devices (HTC Touch Diamond and a device from SonyEricsson) and a flatscreen TV by LG with more than acceptable performance. Although many speculated on JavaFX's future, Larry Ellison made a clear statement during the show that he likes JavaFX so much that he wants to continue the investment and even do a rewrite of OpenOffice with JavaFX. I'm not sure if that's a good idea, but these statements took some pressure off of the shoulders of our friends at the JavaFX team.

Not very surprising was the unveiling of the Java Store, think Apple App Store for iPhone and iTouch, but then for any type of Java application. It seems like we are finally getting a component marketplace for us Java developers.

Last but not least a couple of days before JavaOne the next release of JavaFX 1.2 was released, with as biggest improvements: performance, documentation and API cleanup, new components (codename Caspian) and charting. For more info about what's new in 1.2 check out Stephen Chin's blog. JavaFX engineers Richard Bair and Jasper Potts annouced a new blog: FXExperience where they'll teach us some neat JavaFX tips and tricks.

It hasn't been communicated much publicly, Tor Norbye mentionned it briefly during the JavaPosse BOF, that a new graphic subsystem is in the works to replace good old AWT and Swing. This will give us an even faster startup time for JavaFX applets and better performance by directly interacting with the hardware of your platform. The ETA for all these JavaFX goodies is 'end of the year', so will we get a release at Devoxx as they did with JavaFX 1.0 last year? Hopefully they realize Devoxx is 1 month earlier this year ;-)

This year cloud is also big news. First we had Amazon AWS (EC2), then Google App Engine and now Sun is joining the party. Java developers will get an API to interact with Sun's cloud infrastructure and get access to virtualized hardware just like EC2 and with a similar pricing model. Very exciting times for startups!

Like every year I try to improve my book collection... So this year I picked up Clean Code by Robert C. Martin, an excellent book that teaches you best practices in writing clean (Java) code and how to keep it that way. Alhough you're probably already aware of most of the best practices described in the book, it reminds you why we're putting up with this effort. It's also usefull to have these arguments at hand when you need to convince your boss or client that unit testing and refactoring is so important. Next to Joshua Bloch's Effective Java 2nd edition, my choice for book of the year.

BeJUG: JavaFX in Practice

noreply@blogger.com (Jo Voordeckers) — Thu, 28 May 2009 18:30:00 +0000

Yesterday I presented a 2 hour session: JavaFX in practice for the Belgium Java Users Group. Download the demos here, and here are the slides:

It's been a very busy year for me: founding my consultancy company, looking for projects and partners, preparing talks for Devoxx and BeJUG and some very long working days completing the first project for Pursuit Consulting. Finally the rush is over and I'll have more time to spend contributing to the community. I'm back... enjoy the slides!

JavaOne 2008 was great

noreply@blogger.com (Jo Voordeckers) — Mon, 26 May 2008 20:11:00 +0000

I finally found the time to sit down and write about my first JavaOne. I had to catch up a lot of work that piled up during the last few weeks before JavaOne while I was rushing to get the JavaFX version of Parleys.com out for the Technical Keynote of Bob Brewin. If you weren't there you can watch it again, it's around 1:09 when Stephan Janssen (founder or Parleys.com / JavaPolis) presents the application.

I know I promised code samples during my technical session, but I haven't had the time to write about them. This will happen over the next few weekends, so stay tuned! In the mean time, people interested in the slides from my session can watch them below.

First of all I'd like to thank all the people I met at JavaOne for the interesting conversations and invites to cool after parties. I had a great time, learned a lot and met some awesome people. I'd also like to thank Sun for the opportunity to show my work during the keynote, it was a pleasure to see it on the big stage and to work closely with the people behind the scenes of the JavaFX Compiler, Runtime and GUI library to get it done in time.

I went to an interesting presentation on "Distributed client-server persistence with JPA" by Alexander Snaps, another Belgian guy I met at the Sun BeLux party. With his framework he tries to solve a huge need in desktop Java, transparant online/offline data persistence. I'd like to see this evolve into a full featured framework, and maybe even contribute to this if I can find the time. Having developped a similar mechanism for a client, a flexible framework for this seems like a huge timesaver for new client-server projects. Although some people believe everyone is online all the time, this is unfortunately not true in practice.
Jasper Potts and Richard Bair of the Nimbus and SwingLabs teams showed their latest work on the "Nimbus L&F". It not only looks better out of the box, it's designed to be flexible for us and the designers. Hottest item of their show was the designer tool, I'm anxiously waiting to try it out. It's basically a vector drawing tool that generates Java2D painter code to feed directly into Nimbus.
Ben Galbraith filled in for Shannon Hickey and Chris Campbell for "Extreme GUI Makeover" and he did a great job. He rewrote the GUI for a mainframe textbased financial application, with nice gradients, animations and rich usability improvements. All the sourcecode can be found here. Thumbs up!
Finally I attended "Filthy Rich Clients, Filthier Richer Clientier" by our friends Romain Guy and Chet Haase. Although the technical content wasn't so surprising to me, it was a hilarious session. They floored me when they pulled off the Flex book trick, gotta give it to 'm, they have a huge sense of humor.
The JavaPosse BOF was great also, lotsa loughs and beer, it was fun!

Bottom line my first JavaOne was a great success, hope to see you all next year!

Java 6 update 10 (N) the war is on!

noreply@blogger.com (Jo Voordeckers) — Sun, 06 Apr 2008 09:12:00 +0000

I've downloaded Java 6u10 Early Access several days ago but it wasn't until today that I tested the new applet plugin in Firefox 3 to see if it could live up to my expectations. And I must admit... excellent job guys, two thumbs up!!

The Applet features I appreciate the most (probably all):

Applet startup time with the quick starter is blazing fast and doesn't slow down the browser
Applets run in their own JVM process and can be isolated to one JVM per applet (finally you can provide your applets with a sane VM and you can kill offending applets without killing your browser)
Support for JNLP (native libraries / custom JVM startup parameters like memory settings, hallelujah)
Customization of JVM launch feedback, no intrusive Sun logo if you want a clean integration (this was a personal request, thanks a lot!)
Improved Java - JavaScript communication (I foresee a bunch of Applet widgets :)

If you don't believe me, try this: NASA world wind (a 3D earth in a webpage) or even Quake2 (Jake2) inside an Applet, no offline installation or drivers or libraries required, just click the link and start playing, insanely incredible!!

Damn, this should have been applets way back in time, but now I truly believe the war for the next gen web platform is on! And again congrats Java 6 update N team, you guys did a hell of job!

JPA not ready for desktop applications

noreply@blogger.com (Jo Voordeckers) — Tue, 01 Apr 2008 18:03:00 +0000

Ever since JPA was released I wanted to use it. Since I'm working on a desktop application in my free time that needed some offline storage I immediately thought about using JPA for this.
All I needed was a small database to bundle with my application, HypersonicSQL (HSQLDB) is the all-java database I've been using with great success for integration testcases for the past few years. It's only 640KB in size and doesn't require an installation. This means it can be used as a library in a WebStart or Applet application.
For my needs HSQLDB + JPA is great, no more messing around with serializing objects to disk or using the Properties API. Using POJOs for user settings and caching online resources sounds great.

However when looking for examples of using JPA in a desktop application I found very few and I soon figured out why...
First I looked at the JPA provider I was familiar with from the J(2)EE world: Hibernate. After getting all it's dependencies I soon figured out why nobody uses JPA in a desktop application. Although the JPA API is lightweight, the JPA Providers aren't as you can see in the graph on the side. The thing that shocked me the most is that all the providers (including dependencies) are at least 4 times the size of the SQL database. Too bad, because the API was designed to also be used in desktop applications and it could be a huge productivity boost, but these outrageous sizes don't make it good candidates for web-deployment.
JPA Provider developers should really think about the desktop application platform and make a serious effort to reduce it's library size and required dependencies!

Compiled JavaFX plugin for Netbeans

noreply@blogger.com (Jo Voordeckers) — Mon, 24 Mar 2008 19:58:00 +0000

Friday the Netbeans JavaFX plugin team released daily public builds of the JavaFX plugin for Compiled JavaFX script.

You'll need the latest Netbeans 6.1 beta daily build to get it up and running.

Then download the daily JavaFX plugin archive (ZIP or TGZ) from their Hudson build server.

Install Netbeans as usual.

Modify the Netbeans config file under [netbeans-install-dir]/etc/netbeans.conf and include the -J-da option inside the quotes for parameter: netbeans_default_options If you don't the JavaFX compiler won't work because of a bug

Unpack the JavaFX plugin archive

Start Netbeans, go to Tools > Plugins > Download

Click add plugins...

Select the .NBM files you unpacked from the plugin archive

Optionally you can choose to use your own versions of the JavaFX Compiler libraries if you build your own version from SVN repository for example.

In Netbeans go to Tools > Libraries

Select JavaFXUserLib

Modify the provided javafxc.jar, javafxrt.jar and Scenario.jar with the ones you prefer

That's it, now you can enjoy (for now): syntax highlighting and compiling JavaFX script from Netbeans. If you want to keep posted on this plugin send an empty mail to their mailing list dev-subscribe@javafx.netbeans.org

Exciting JavaFX

noreply@blogger.com (Jo Voordeckers) — Sat, 08 Mar 2008 12:49:00 +0000

It has been a while since I blogged but there's a very good reason for that. Since a few months I'm spending all my free time on a cool project to be showcased soon. I can't disclose too many details as off yet but I can tell it's a Rich Internet Application prototype written in JavaFX. It started out as a technology proof of concept but it's taking on the form of a real application. In the mean time without unveiling too much yet I can give some pointers and lessons learned while discovering the JavaFX language.

Getting started with JavaFX

When starting with JavaFX Script an easy way to start is to try one of the webstart demo's on the Chris Oliver blog. Try out the links with JavaFX Pad, these allow you to modify the FX script code and get immediate feedback from the JavaFX interpreter. This way you get to know play with FX Scripting language, without really having to install anything.

At this point you need to know that the FX interpreter is a prototype so the FX Script syntax will be different in the final product of the JavaFX compiler. As most documentation and examples on the web (excluding the latest examples on Jim Weaver's Blog) use the interpreter syntax and the FX Compiler is incomplete, it's best to get aquainted with the language like this and move on to the FX compiler understand how everything work.

IDE

When developing in FX interpreter syntax you have the luxury of a Netbeans and Eclipse plugin to help you out with code completion, syntax highlighting, some javafxdoc and real-time script execution results. They can be found here https://openjfx.dev.java.net/#downloads
Getting started with Netbeans is explained here https://openjfx.dev.java.net/Getting_Started_With_JavaFX.html

Documentation

When you get around playing with Chris's examples a good place to start looking for more answers on the language constructs is https://openjfx.dev.java.net/JavaFX_Programming_Language.html
and https://openjfx.dev.java.net/Learning_More_About_JavaFX.html.
The JavaFXDoc API for the FX Script classes can be found here https://openjfx.dev.java.net/nonav/api/
There's also a Wiki with a lot of JavaFX related information, examples, components, know issues, requests etc. on http://jfx.wikia.com/wiki/Main_Page

Forums

More and more people monitor and post regularly on the OpenJFX forums, it's a good place to ask for help for the FX interpreter syntax, the forums can be found at http://forums.java.net/jive/category.jspa?categoryID=62

The compiler

If you really want to start working with the bleeding edge FX compiler under development you should subscribe to the OpenJFX Compiler mailinglist (dev@openjfx-compiler.dev.java.net), monitor their JIRA issue tracker and SVN commits (commits@openjfx-compiler.dev.java.net). There isn't any documentation up to date on the compiler syntax yet, but you can look in the source and the numerous examples inside. There is however a dated page on the Wiki on the differences between the interpreter and compiler.
As I'm in the middle of such a conversion I started a shared Google Docs page where I log all my issues and workarounds: this is a work in progress and has as main goal to be merged with the Wiki page once I finish my conversion. Everyone can request write access to this document, this way as a community we can improve the documentation. Feel free to join in on this effort!
Another great source for information is Jim Weaver's blog where he posts new examples on learning the new compiled FX Script syntax on a daily basis.

So now with all this information assembled I hope more and more people will find their way into this exciting new technology. With this first post on the subject I'm hoping to start a series of JavaFX related posts that will help people get to know all about it and why it's potentially the biggest leap for desktop Java.

Google Web Toolkit by Microsoft = Volta

noreply@blogger.com (Jo Voordeckers) — Tue, 30 Oct 2007 11:09:00 +0000

Apparently Microsoft is working on a new product (Volta) to improve web development. Basically it boils down to a GWT-like approach. It's a VisualStudio plugin that compiles msil-code to JavaScript (or Flash or Silverlight) for the client tier.
They claim that it's only used internally but it wont surprise me if they release it to interrupt the fast adoption of the GWT technology.

Flex vs GWT vs Echo2

noreply@blogger.com (Jo Voordeckers) — Tue, 23 Oct 2007 10:08:00 +0000

Past 2 weeks I needed to investigate the best framework to port the front-end of a Java/Swing framework to a rich web UI environment.
The contenders:

Adobe Flex2
GWT (Google Web Toolkit)
NextApp Echo2

The idea was to have a rich UI similar to the existing Swing framework running inside the web browser, that seamlessly integrates with existing Struts webapps. Applets / WebStart was out of the question, because of fear for deployment and decompilation issues.

So with these constraints in mind I started looking for the best framework amongst our 3 contenders. The odd one in the list is obviously Flex, but although not based on DHTML and JS it offers a lot of richness, and the deployment and security risks where less of a concern to the client.

Echo2 soon failed one of the main constraints: to seamlessly integrate within other webapps, maybe there are good solutions but I didn't seem to come across those. Because the API was very similar to Swing it was very easy to port some of the basic functionality for my proof of concept, too bad. Another concern is that Echo2 maintains the view-state server side, which could become an issue when scaling up to many concurrent users.

Flex also failed in favor of GWT. The main concern was the difficulty to integrate it with a J2EE or JEE backend, you need to use WebServices or REST. There is a free version of LiveCycleDataServices which takes care of this but it's limited to single CPU systems. Licenses for the enterprise edition however are pricey. Another concern was the lack of quality opensource plugins for Eclipse, requiring a FlexBuilder license at 500€ per developer to have a comfortable productive development environment. And another inconvenience is that it's not Java, rather annoying to migrate all developers to this new language (ActionScript). Flex still has to prove itself as a technology ready for enterprise adoption, and you still need a browser plugin and it can be decompiled.

GWT on the other hand doesn't require all those changes of habit, you can keep developing and debugging in Java, with your preferred and well known tooling, JUnit testing, refactoring, you name it. Now a year after the first release there's already a large community adopting and extending the framework. Numerous enterprise applications have been built with it and it seems like a platform that improves productivity for rich internet application development. GWT shields all HTML, CSS, DHTML, JS and browser incompatibility issues from the developer. And as bonus you get free client side code compression and obfuscation. It's a pure WIN WIN situation.

A first implementation of the web port of the Swing based framework has begun with GWT 1.4.60 as platform and GWT-EXT (wrapper around EXT-JS) for some richer UI widgets. Everything gets built by Maven2, is developed in Eclipse and tested and debugged in the GWT Development Shell.

With the inception of GWT, Google gave JavaScript based applications a second life. IMHO if it wasn't for GWT, JavaScript would be dropped rather sooner than later in favor of Swing / JavaFX / Silverlight or Flex-like solutions for enterprise applications because of project maintainability issues.

Be sure to tune in later when I post my GWT / Maven2 project setup for Eclipse...

Java Memory Leaks

noreply@blogger.com (Jo Voordeckers) — Sat, 22 Sep 2007 12:12:00 +0000

Yesterday is stumbled upon some interesting blog posts by Scott Violet from the (former) Swing Team and Tim Boudreau from Netbeans. Apparently Swing action listeners before Java 6.0 were registered, and as such tied with normal references instead of Weak References causing unused objects to remain in memory. So if you're developing in pre-6.0 be sure to think about this issue, you're most likely preventing unused memory for liberation by the garbage collector (= memory leak, yes Java has memory leaks too!). Second concern is that still a lot of Swing developers tend to extends Swing components:

public class MyFrame extends JFrame {}

This has the unfortunate effect that the GC needs more passes (at least 2) to recollect unused memory. This is because somewhere up in the inheritance graph Component implements finalize() causing the GC to do extra effort to collect memory because it needs to run the finalizer and then reschedule another GC pass. So in case you're just USING the Swing components and not adding features, use them like you use other Java objects like ArrayList, HashMap,... It's a quote from Erich Gamma: 'Favor composition over inheritance'.

Although memory leaks are more likely to happen in combination with, they're not limited to Swing. There are other concerns: static inner classes, misplaced fields with respect to their scope, collections used as cache, ... You don't do it on purpose and there are commercial profilers that do a good job in detecting these issues but you need to find them yourself. However the Netbeans team has a nice tool to test for these errors. The extended the JUnit TestCase with a method: assertGC() to test if a certain object reference can be GCed or not. If not they launch the INSANE library to detect which chain of objects is still referencing your object, and so preventing it from garbage collection. Their files can be found here with an easy example: Tim Boudreau in his LeakDemo source code. Take note that the example now correctly passes the JUnit test because of the adaptions in Swing from Java 6.0, but it explains how to work with the test-cases.

Playing Flash Video (FLV) with Java

noreply@blogger.com (Jo Voordeckers) — Tue, 18 Sep 2007 22:11:00 +0000

*** Update: Read this post first!! ***

Today I was challenged by one of my coworkers to be able play an FLV movie inside a Java client (Swing) application. Well it seems like it's a piece of cake. All you need:

JMF
FOBS4JMF
Adapted JMF.properties file
.FLV file (I took one of the talks @ Parleys.com)

To spice up the challenge I added the player inside the ReflectionPanel from the great book: Filthy Rich Clients.
There's nothing special to it... I created this demo in about 15minutes. If you take the FOBS4JMF binary build, all you need is included and preconfigured.

Swing Debugging

noreply@blogger.com (Jo Voordeckers) — Wed, 12 Sep 2007 07:49:00 +0000

Kirill Grouchnikov wrote a nice article on the subject of Swing Debugging. This is still a dark area for newcomers to Swing application development. Blocking the EDT (Event Dispatch Thread) or updating Swing components off the EDT are common problem areas for newcomers and contribute to the fact that people think that Swing is crapy or slow.
Fortunately some people have contributed tools to verify against these violations, you can find 2 classes for debugging Swing here (CheckThreadViolationRepaintManager and EventDispatchThreadHangMonitor).

OpenLaszlo vs Flex

noreply@blogger.com (Jo Voordeckers) — Sun, 26 Aug 2007 13:20:00 +0000

When talking with some colleagues on the subject: Java Swing rich client vs rich web-client RIA, we came across the new Flex2 and Flex3 technology as alternative to Web2.0 AJAX styled RIA.
I first came in touch with Flex at the JavaPolis event last year, but I wasn't too excited, being more of a desktop application guy. But when you start to think about it, it makes sense in such a comparison. It seems to improve productivity, is widely available on all common platforms, is configurable, styleable, ... what not!?
So in my search for a good comparison of Flex vs other technologies I came across another contender: OpenLaszlo - 'the premier open-source platform for rich internet applications'. After seeing the demo applications I was amazed by this framework. It's so easy to do many of the most common things and the best part is that it generates both Flash and DHTML so it's not only dependant on your Flash plugin. Flex also has a lot of nice demos, somehow feels a little smoother and now has a free SDK. Now it's just a mather of trying them out to determince which one is the best to work with. To be continued...

Swing application architecture

noreply@blogger.com (Jo Voordeckers) — Thu, 28 Jun 2007 19:57:00 +0000

In my previous post I talked about a presentation I'm preparing, related to this and a course i'm teaching in advanced desktop Java development I'm thinking about 'the best practice' architecture for a Java Swing 'rich client' type of application. More specifically I'm looking for an all round solution to separate business and GUI layers, pass around events, prevent EDT blocking, (asynchronous) tasks.
After having read Desktop Java Live by Scott Delap (great book by the way) I'm not entirely convinced by his RSS Reader example., I do things differently, not necessarily better. After a talk with Karsten Lentzsch (JGoodies.com) I'm still somewhat in the dark. It looks like there is no correct answer, just some guideline into the right direction. Use PresentationModel's and an application-level model to interconnect larger graphs of PM's together. Maybe the EventBus could come in handy here, but I still haven't tried it.

Desktop Java on dope

noreply@blogger.com (Jo Voordeckers) — Tue, 29 May 2007 22:46:00 +0000

It's been a while since I wrote here, mostly because I'm occupied with a new task besides my daily consultancy job at the client. I'm preparing a presentation on Desktop Java. More specifically focussed on Rich Client Java Apps with Swing. So the past few weeks I've been going over and over all JavaOne 2006, 2007 and JavaPolis 2006 desktop related presentations to make sure I didn't miss anything.
So far Java 6 seems promising for the Desktop developer, but as always it will take 3 or 4 more years until the businesses start adopting it. Heck I would love to just be able to start using Java 5, but the client I'm working at is still stuck at 1.4 :-( Too bad, no annotations, no generics, no SwingX or other cool components based on Java 5... I've actually been back porting quite a lot because of this. May this be a call out to all Swing component writers... preserve 1.4 compatibility for just a little longer please!

It's somewhat remarkable that desktop Java is making a serious come-back, all the UI bug fixes and improvements put into Java 6 and the promising upcoming JavaFX , Swing App. Framework, Beans Binding. Desktop Java is finally evolving rapidly, and that's good news but for now using JGoodies SwingSuite can get you started today with the technologies promised for Java 7.
Another thing I noticed is that Eclipse platform is also gaining momentum, so I'm expecting some more EclipseRCP / SWT projects in the near future.

Hello World and welcome

noreply@blogger.com (Jo Voordeckers) — Tue, 27 Mar 2007 21:46:00 +0000

I will be spending some time here in the near future to make comments and write articles about subjects that matter to me, my job as a Senior Software Engineer / Technical Project Lead, and my life in general...

Enjoy the reading!