JavaZone 2007: Java Persistence on the Client

I am back from my Oslo trip. JavaZone 2007 was again a great success! The exhibition hall was much bigger than the hotel lobby last year, much more decorated and with even more people attending! Still it remained a very enjoyable event… I had a really great time and many possibilities to chat with interesting people: attendees, the JavaDB guys and with speakers that I either met for the first time or was really glad to see again. Here’s a small video by Dion Almaer from Ajaxian.com, so that you make sure not to miss it next year.
[youtube http://www.youtube.com/watch?v=Rizm8-6foCE]

My BOF on Choosing the right framework for your next web-application turned out to be overcrowded. But I really had a hard getting the audience participate. I really didn’t wanted to compare web frameworks, but rather discuss the subject and criteria to keep on mind when doing so. All depending on the kind of application you are about to write. I am not really sure comparing them would make much sense, and besides Matt Raible was already doing a talk on the subject… It was still clear that many people feel it pretty hard to make a choicegiven the many people attending. JavaZone organizer Tobias Torrissen explained me afterwards that Scandinavian people don’t feel to comfortable speaking up in such situation…

My talk on Java Persistence on the Client went almost OK. The Apple Java VM gave up on me properly dispatching window event to AWT, so that I got a stack trace on trying to move the window around… I had tried the two demos like 20 times before, but never with a second screen hooked-up to my MacBook Pro!
I also got some interesting details from Mike Keith about the behavior of JPA not updating managed entities when these happen outside a transaction. And, while my statement during the presentation is still correct, you can actually have changes made to entities outside a transaction being propagated, beginning and committing a transaction at anytime. Which is actually a very nice feature in the end, enabling you to not have long during transaction on the database. I’ve modified the code example to the RichClient demo to reflect that behavior…

Demos and slides are available.

• The first demo is Console: a small Swing application that enables you to run queries on the embedded Java DB instance.
  The test directory contains a JUnit test class on which you might want to run the method creating the persons table and then the one inserting 25k lines in it. This might enable you to run some queries to check out the performance…
• The second demo is RichClient, that relies on the Model module. Model are two simple JPA entities. RichClient will create again 25k instances of Person that it will persist into the embedded Java DB, the first time you click the Refresh button. You can then repress that same button to load all these in the JTable. Clicking on a row will fire an event globally to all controller. The PersonFormController will receive that event, and use the Person entity it contains to load its own. You’ll then see how easy it gets to set the Company of that Person into the JComboBox as object identity is handled for you by the JPA implementation.
  Should you type in more than 32 characters as the Person’s first name, the database will throw an exception at you. As the cancel button uses the database to “refresh” the instance, that will now fail from now on, that instance not being managed anymore. The same is true for the initially loaded Company instances, so that they can’t be compared anymore using == with newly the one Company instance from a newly loaded Person instance.
  The idea beyond the HMVC stuff, is to be able to have different controllers use different EntityManagers. This eases the handling of exception, as triggered by the entity manager, it will detached all its instances…
  Christian Bauer had a blog entry on the subject on the In relation to… blog, but it seemed to have disappeared!
  If you want to see what happens at the database level, change toplink’s logging level to fine within the persistence.xml file.

To run the Console demo, you’ll simply need a JDK 6 and the derby.jar file it contains to get Java DB. The second demo requires a JPA implementation. The contained persistence.xml file is configured for TopLink essentials.

I hope it inspires some of you…