A working app is an ideal substitute for a formal specification of just exactly how feature ‘X’ is supposed to work, particularly if you weren’t involved in the original design decisions, development cycle, bug fixing and so on. It’s easy to look at something and, based on your impressions of what it should do, write replacement code – however you can often end up throwing the baby out with the bathwater in doing so.

Martin Fowler describes code refactoring as “a series of small behavior preserving transformations.” (www.refactoring.com) and he’s spent a lot more time analyzing, writing about and probably doing refactoring than most people. This approach has consistently worked well for me over the years.

The Cocoa Java bridge is the Obj-C Java bridge. There is not a separate bridge. More specifically, Cocoa-Java uses the Obj-C Java bridge to do it’s work.

As long as there is a Java SDK on Mac OS X you will be able to use JNI to get to Java from Obj-C since JNI is part of Java. I don’t expect that to ever go away unless Apple drops Java entirely, which is extremely unlikely.

As far as the bridge is concerned, I believe Apple has stated that the bridge will still exist on Leopard, but there are no guarantees after that. So it may or may not be included or work in 10.6, and users of the bridge best be prepared for it to not be available.

I wonder how it could apply to a language that doesn’t have an Objective-C bridge, like RealBasic or .NET via mono.

I’ve found the “keep it working” approach to be better for me as well, especially since this is a side hobby project and I don’t get very much time to work on it. I did some major refactoring a while back and the app wasn’t runnable for a couple of months. I found that to be quite frustrating, especially when my planned refactorings brought on even more changes and I felt like I was getting farther behind with each step instead of making progress.

I’m trying to avoid adding any new Java code, and doing everything new in Obj-C as much as I can. One approach I’ve tried for the few times when I need to call from Java into Obj-C is to (ab)use notifications. It doesn’t always feel right, but is easy to implement and keeps me away from bridget, which I am also loathe to use and have avoided thus far.

I am going to have to try this Chimera approach and see if I can make it work. I look forward to your porting tricks, as I have much porting still ahead of me.

My approach to development is to do it incrementally, in the smallest functional working blocks at a time. It’s not always possible, but when it is, it makes writing the code much easier.

Using the “incremental and almost never broken” technique, I just get a bit more security that I’m not breaking things terribly, as I go. I would be more likely to be adventurous with a product that I knew extremely well. In this case I have the added pleasure of a continuous reference for functionality. I don’t have to compare with the original product, to see if it behaves the same. I can constantly compare against my last checkin, to see if I busted anything.

Is this more of an aesthetic thing for you? I keep my code up to date in my svn repository in case I need to roll back, so it’s not really a giant issue to me when I break things.