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

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

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

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

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 SunOracle, 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

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.

1. 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. 
2. 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.
   
3.  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.
4. 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.
5. 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.
   
6. 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.
7. 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.
8. 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?

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

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

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!