One of the new wiz-bang features of the JLCA version 3.0 is support for converting the Swing package to .NET. This numerically performs great, but there is one hole that brings almost every conversion to a screeching halt: Layout Managers. The .NET framework doesn’t currently have a concept of Layout Managers that a Java Programmer would recognize. You can anchor controls which can approximate BorderLayout and FlowLayout is kind-of the default in C# but what about the others? Remember the phrase up-a-creek? Currently your options are limited to not using LayoutManagers in your Java code (like that is really an option) or having LayoutManagers implemented on the .NET Framework. For those of us that don’t really have the time or inclination to re-code Gridbag in C# there are 3rd parties that sell C# versions of all the LayoutManagers. For those of us that find our money more limited than our time check out: http://www.csharphelp.com/archives/archive7.html for a good starting place. Matthew Johnson wrote a short article on LayoutManagers in C# and generously provides implementations of Flow, Grid, and Border Layouts. If your Swing application wasn’t overly complicated this might be all that you need. Those that went all out with GridBagConstraints can still use Matthew’s foundation classes as a starting point for your own LayoutManagers. (Hmm, sounds like a good excuse to start a small series of posts one on each of the missing LayoutManagers… We’ll see what my schedule is like in the next few weeks.)
The JLCA will work with these new LayoutManager right? Sorry. Oh wait, did you want something more than the short answer? You will convert your application as usual, receive LayoutManager errors and then “quickly” fix them by changing the non-converted Java calls to C# calls into your newly bought/written .NET LayoutManagers. Shouldn’t the tool do this automatically? Maybe. This ties back to not supporting 3rd party any-things that I mentioned in my introduction to the JLCA. But (you knew there had to be a ‘but’ since I wrote this post) you can make your life a little easier if you plan on running the conversion multiple times. I.e. you only have to do the work once instead of after every conversion. How you ask? Well it is all about the difference between 3rd party libs and your source code. Why can the JLCA convert your code but not that nifty logging utility? The simplest of answers; you have the Java-source to your code. How does that help us if the LayoutManager source is in C#? It doesn’t, but if you created (I propose this being done programmatically) a tool that took your C# code and created Java stubs of the public methods and members (also the protected ones if you extended any of the LayoutManagers) you would have Java code. Then you refactor your imports from the standard javax.swing.XYZ to my.stub.XYZ and the next time you convert the JLCA will convert your source plus your stubs. You have effectively fooled the JLCA into thinking you have the source to these LayoutManagers. Assuming you used the same package structure and class names as the C# you can now overwrite the converted stubs with the actual C# implementations and bingo: conversion without the LayoutManager errors. Sounds like a crap-load of work huh? Well I did warn you it was really only really an option if you planned on doing multiple conversions. At that point you could justify the up-front cost by not having to repeat the post-conversion work every time. Is this the only solution? Not by a long shot; remember the good old Extensibility Kit? This is of course the poster child case for that tool. And while I haven’t purchased any of the 3rd party toolsets I am sure they have their own creative ways of dealing with this tedious issue.
Completely off topic, if any of you haven’t seen the new movie Monster yet I would suggest you wait for the video store. I would say that it was the best acting I have ever seen in a made-for-TV movie. Honestly, the acting is very good. Charlize Theron and Christina Ricci do great jobs. It’s just that the story lacks drive. A friend summed it up by saying that the movie “lacked climax” (and before you think this a bad pun on the lesbian scenes; it was a female friend and her mind isn’t in the gutter.) A different friend said that it was the first time he had paid to see a documentary. No one expected a fiery, explosion-filled ending, but I left the theater wondering where they had wanted to go with the movie, and why hadn’t we gotten past the start line.