Not quite dead yet…

Despite not having posted here for almost two years now, I’m not dead yet…
It’s been a year now, I joined Terracotta to work on their Hibernate second level cache implementation. A lot as happened since: Terracotta acquired Ehcache and Quartz, which gave the transparency team I joined some work…

My latest work there has been on Ehcache and its JTA support. Ehcache 2.1.0 beta has just been released with a whole bunch of new features. I’m planning on putting a post together on using JTA (and the coherent methods added to this release) with Ehcache in some very near future…

Not quite dead yet…

Jazoon Presentation on Distributed Client/Server Persistence

I’ve presented at this year’s Jazoon conference on Hölchoko, a framework for distributing the persistence of your JPA domain models to multiple clients. While the project itself is not where I would have expected it to be by now, I’ve finished enough of the demos to show what the idea is all about.
I’ve uploaded the presentation here. I know the demo still has the encumbrance of IntelliJ Idea forms for parts of the UI. I hope to get enough time to remove these very soon.

I plan on closing the remain tickets and release version 0.9.1 somewhere next week. I know the type system abstraction still requires quite some work. Finishing the remote filter for sending entities back to the server is just a matter of back porting from the in production systems and developing the dynamic proxy I show in the presentation. Code cleanup is still an issue and so is JavaDoc! HMVC is pretty there already…

Jazoon Presentation on Distributed Client/Server Persistence

Hudson continuous build full screen monitoring

I’ve just quickly hacked a fullscreen monitor for our continuous integration server at work. As for my personal projects, we use Hudson, which has a nice restful xml API.This small utility asks for the url of your Hudson server and retrieves all the jobs and their status. You can also provide the url to a view, would you want to only partially monitor your jobs (such as only the continuous integration builds, ignoring nightly builds, or the other way around).

HudsonMonitor Main screen

When in full screen mode, the tool will poll the server every 15 seconds for job updates and render a fully red, yellow or blue (and yes, I kept the blue!) screen displaying the worse status of your currently monitored jobs. Should the screen not be blue (all monitored builds stable), it will also display the list of unstable or broken builds.

HudsonMonitor - Full screen mode

Everything is pretty much hacked together, with way too many inner classes (lazy me!). This is what I call a “one movie hack”, as I quickly wrote this with the computer on my lap next to my wife while we were watching a movie… or at least she was! Besides, it uses the IntelliJ Idea’s layout manager for the main screen. I’ll try to clean this all up. In the meantime the code is available through a:

svn co http://www.codespot.net/svn/repos/HudsonMonitor/trunk HudsonMonitor

and the executable jar is available here.

Hudson continuous build full screen monitoring

On testing…

Earlier this week I’ve received the Javalobby newsletter featuring an article by Antonio Goncalves on Why are we not using Java EE 5? While there is much to be discussed on the subject, I’ve been thinking about his statement on testing :
Testing a Java EE 5 application is definitely not as easy as a Spring application. We live in a world where everybody talks about test, but nobody really does it. Java EE 5 doesn’t help in this aspect.

I am not really sure he means Java EE 5 applications aren’t easier to test than ones written based on previous specification versions, because if he is, I don’t agree with that statement. If it is Java EE 5 promoting testing practices on developers, well that is probably outside of its scope anyways. But still that statement would probably have me being a double nobody, as I do use Java EE 5 (or at least on a few previous missions) and am among the ones that talk about testing, but also am definitively doing it! Yet probably not enough and have a really hard time getting developers on my team doing it properly…

Testing is surely a misunderstood subject. I even have been recently asked by some paper architect to draw a clean line between unit and functional tests! There is indeed much effort to be put in having developers to write pure unit tests. Ones that do not go to the database or the file system. Unit test that try to assess the completeness of the smallest piece of code possible. The Pragmatic Programmer’s book Pragmatic Unit Testing in Java with JUnit is a great source for developers starting with unit testing. I actually missed the exception on providing the empty array to the simple example used as introduction!
But after you a while you eventually really get into it. And it becomes as straight forward as testing your code manually… All tests should be run fast, within a few seconds and before every commit to the SCM system. Or at least on the ones on the module you just made changes to!

Integration tests, the ones that actually make sure that all your pieces work together in the intended manner, have also become pretty straight forward. These two sets of test give, in my humble opinion at least, developer a pretty good coverage of the application they are delivering. I currently use Hudson as my preferred continuous integration server, so we’ve installed a rogue server on our floor to run a real continuous integration as the company infrastructure team only provides nightly Cruise Control builds.

But this is the only point to which we’ve got yet in our 40 man big team… And, yes, of course we have quite some technical debt, and not only on the unit test front! But we really need to start improving on the system tests and more specifically functional tests. I am currently spending quite some time investigating on Model-based Testing. So I envisaged introducing ModelJUnit by Mark Utting into our test plans for the near future. I think that Groovy might be a good match there too, especially if we manage to get analyst to write these test themselves… Yet I think this might lead them to produce even more documents before they actually get going. Finite State Machine diagrams might be a start…
We are currently also still trying to introduce database deltas into the whole picture and maybe our own custom continuous deployment server, because of some delivery system the Agile coach for the company would like to put in place… But more on this later should we get there.

So this is my current state with testing. And while Antonio is probably not entirely wrong, I really hope that he is not right when he says that nobody really does it. What is your status on testing within your project or company?

On testing…

Beans Binding & JPA

I have been continuing my work on integrating Beans Binding (JSR 295) and the Swing Application Framework (JSR 296) with the work I have been doing on providing a JPA enabled HMVC framework for Swing developers. I must already say that getting to the information on how to exactly use these two apis isn’t straight forward. JavaDoc is probably not what it should be. I can’t really blame them on this, as I am probably the worst candidate for this exercise. Document, as in RTFM, is completely nonexistent.
As I was coding on some UI parts of the demo application for this, I got mail about the issue I mentioned earlier with the NetBeans example code. It seems either the Beans Binding stuff (more specifically its ObservableList implementation) has issues dealing with the same elements being removed and added back again to the Collection.
Indeed, I was executing a Query on the EntityManager returning the same Set of instances (as the EntityManager will take care of Object Identity for you), but this seems to break some bindings (NPE). I could figure out why yet though! I didn’t got it first, as the mail stated that this behavior was not reproducible with the initial transaction management, as generated by NetBeans. But then it came clear, as I was reverting the changes, that the RefreshTask was rollbacking the transaction, causing managed instances to become detached and the Query hence returning new object instances for every row from the table.
I fixed this for now by calling a EntityManager.clear() while doing the refresh. I think this is pretty ugly, as I would expect object identity to be something I want to be able to rely on, especially in such long living applications as Swing rich client apps.

Bad news is that I found about a downside of my approach. But I guess this is probably more related to me trying to fix a inherently broken example…

Beans Binding & JPA

JavaPolis, NetBeans 6 & Season's coding…

That’s it JavaPolis is over. It was a great success again and completely sold out weeks before it actually began… It was a great opportunity for me to catch up with old friends and time to make some new. The French speaking community was pretty present and I was really pleased to chat with people I had not seen since the Sun Tech Days in Paris in February.
Bruce Eckel tried to introduced the Open Space concept to the event this year. While I haven’t had a chance to participate in any of the round tables, I think it was pretty quiet on that side of the venue… Sad, as the CITCON in Brussels, which was my actual first unconference, has convinced me completely of the format!
Other highlights for me of this year’s conference would have been the BOFs on Closures and future language features that might (or not) be introduced. Joshua Bloch changed his actual conference slot last minute for “The Closure Controversy”. And I am part of the people that have changed their mind in favor of not introducing these in language after all. This session would probably have made the conference for me, even if it would have been the only session I had attended.

During a less interesting keynote (for me at least), I decided to launch NetBeans 6 that I installed ever since it was released, but yet had no chance to look at. One thing that NetBeans got really strong in, would be GUI. I remember getting Matisse demoed a few years back in San Francisco. While I might not give up on IntelliJ Idea any time soon, I still like to have a look at every new major release. So the first thing I did after it launched, was creating a JSR 295 / 296 application. I couldn’t resist to go for the database one, using JPA.
I remember Hans Muller’s session during last year’s JavaPolis, where during a demo I saw some weird code about transaction management. As soon as the project was setup, I had to realize that this transaction management made it in NetBeans example code! Besides the fact that every client would have a long living transaction on the database back-end, which probably wouldn’t be what you’d want on production sites, this kind of transaction management can lead to weird behaviors.
As I was sitting next to Vincent Brabant, I quickly added a button to the UI to generate a Query that would force the EntityManager to flush changes to the database, while the user would not yet have decided on whether he wanted his changes to be persisted. On top of that pressing the generated Refresh button would make the behavior of the application even more confusing to the user… I used that to demonstrate my point to Vincent. Provided an alternative implementation that solve this issues and have him provide feedback to whom ever might help on this.
On my other side was sitting a colleague of mine, he quickly also discovered by looking over my shoulder, as he is much more of a Swing expert than I am, that Tasks were accessing Swing components from another thread than the EDT. That all left me with a weird first opinion on NetBeans 6! I really believe Sun should try to put more effort on providing meaningful example code to developers. Especially junior ones! It is so easy to screw people’s mind up… Swing and the EDT are so misunderstood by many developers out there. It would be important to communicate better around this stuff. Same is true for JPA! Hibernate is probably the most misunderstood, yet widely used, tool out there. It would be nice if JPA developer could try to avoid picking up on these bad habits.

So after a week full of great informal chats and technology show cases, I got back to work. Not had much time to do anything useful, still I managed to think a bit. While I am still in the process of completely rewriting the Hibernate implementation of my “distributed JPA” tool before releasing it, I also try to correlate what the Sun guys have done with JSR 295 & 296 with the stuff I have been doing on HMVC with JPA for Swing apps.
I hope I will finally be releasing my work on Distributed JPA entities by the end of my holidays, within two weeks that is. I’ll then do my best to get something going this Swing “framework” thingy.
Another demo at JavaPolis by François Orsini and Jean-François Arcand on JavaDB and Comet got me inspired for a nice proof of concept for all these thing. Hopefully I’ll be able to tell more soon. But even if I cannot get to put all the effort I would like to into it, some other guy I spend the night with in back in Brussels after JavaPolis offered to have a look into it as soon as I get more on it done…
So cool stuff for this season’s coding! This will be a pretty full two weeks of holidays. Hopefully my daughters let me get to some coding…

JavaPolis, NetBeans 6 & Season's coding…