We are indeed very proud of our two screens setup. I can tell you that it helped productability too – Having the document describing the client request and design to follow on one screen and the code on the other is more helpful than can be assumed.

2. By non phone Java I simply meant JSE and JEE (which, in fact, uses the JSE JVM). I should have been clearer.

I am specifically excluding JME (my current project) and smaller; it appears those JVMs aren’t up to snuff performance wise, although its hard to compare since there isn’t that much native code on, for example, phones (plus JME uses a lot more of the native api, which further clouds the issue). On the other hand, there is a robust market in Java games (i.e. computationally aggressive applications) for the phone – go figure.

1. You don’t really see the generated code. It’s hidden in a collapsed box you can double click in order to really see inside it. This is similar to dotNet’s #region tags, if you are familiar with them, or with the way NetBeans, Eclipse and IntelliJ are collapsing code inside code blocks (between the curly brackets). That’s why it doesn’t bother me much: It’s there, but I don’t see it.

2. At work I have two screens for development. I find it highly comfortable to drag out all the frequently used windows such as project explorer and debug windows, so that they are still always open (as opposed to un-pinned) while still getting a full screen window for my code writing. That’s why I like floating windows.

3. I don’t understand “non phone java”. However, I agree that your thoughts might be true. I made the IB test on my laptop, which is low on memory in general. A lot of swapping must have occured, which is likely the reason for IB running much smoother. However, it’s also due to Java’s framework taking up the amount of memory causing a lot of swapping, so it’s not free from blame.

Thanks again for commenting!

0. I haven’t been playing with Matisse yet, so my questions are necessarily more general.

1. I gather that you don’t find the mix of generated and non-generated code an issue.

Theoretically, it seems somewhat messy to have the two co-existing in the same file, plus it would seem to add needless visual clutter. Said another way, if Matisse is separating out the layout and the logic, I submit that it should carry that through to its logical conclusion and have separate files – if developers don’t have to futz with the code, they shouldn’t have it in their face unless they ask for it (turn on the show-code option).

This would partly address your original point about no XML storage of the layout. Sure its not XML, but at least its separated out, and as long as you don’t see it, who cares what the format is, assuming you’re sticking with Java.

In fairness to Matisse, this would seem like a V2.0 polish thing. At least we have something now, for a change, that is functionally competitive with the leaders in this space.

It would be slick to have the event handlers pop up from inside Matisse, as I was saying; more v2.0 polish. Interesting that IB doesn’t do this – there’s polish that IB is missing.

2. Interesting that you find floating windows easier to use than a split pane. Is it possible to “un-pin” them in Netbeans and make them standalone windows/drag them out of the frame? If not, hopefully this will be added, in general – its useful, for all windows. Netbeans 4.1 was starting to get into this – you could collapse pretty much all of the subwindows, and if you were running in full screen mode it was almost as good as floating. You may have even been able to drag them out of the window; memory fuzzy here, for some reason I didn’t do that (window title bar too big?). Of course this assumes the windows themselves are small and well designed. Possibly more 2.0 polish there, too.

3. Your speed observation is interesting. Non phone Java, ignoring startup time and memory footprint, is claimed to be competitive with native code, roughly (particularily for non GUI), yet you aren’t experiencing that. I wonder if its a memory footprint issue (not enough actual memory/swapping – Java crawls in that case), an optimization issue with Matisse (probably, to some degree; its early after all – we have to be fair), or if Java still isn’t quite there yet, at least for gui performance, at least on the Mac. There was some talk that changing the garbage collection parameters helped with performance (stopped gc pauses, which was annoying in 4.1).

I believe Apple still hasn’t turned on hardware accelerated graphics in JDK 1.5/1.4 – that would probably make a big difference. I wonder how Matisse performs on Doze, where there is hardware accelerated graphics? Perhaps this is more experimentation than you care to do.

4. The cross IDE nature of Matisse is very slick. It sounds like we have a clear winner, at long last – one of the 3 big remaining Java issues, in my opinion, is finished (the other two being multiple apps in the same JVM, JSR 121 (underway, and its taking longer than expected), and orthogonal persistence (the Java object model drives persistence; JSR 20, stillborn)

I can only guess that somehow you wrote your comment while I was writing mine, and so your comment actutally refers to my previous rather than the later comment.

I will answer what’s left unanswered, though:

There really isn’t a flame war coming. I didn’t develop any Cocoa application, only toyed with it at the time when I realised XCode was coming free with the OS.

About having anything in IB missing in Matisse, and about the Mac’s “feel”, I think I answered those in my comment, so I’ll move on.

Regarding to whether Matisse plays nicely on the Aqua theme, I can say that it does. Since Matisse is running over normal Swing, Apple’s look and feel for Aqua takes place and it feels at home. The only thing I noticed differently was the “Save” dialog, not looking like a standard Aqua save dialog. I wonder if that’s intentional though.

By header I actually do mean the method signature. More than that – Even the closing curly bracket, ending the method, is read only. I haven’t tried messing the signatures of event methods to see if they can be regenerated, but it’s a nice idea. I will try that.

Regarding the new level of inheritence, let me see if I folllow: Create a class inheriting from JFrame, place all event handling and component creation code (the auto-generated parts) there, and then inherit from it and leave the inherited class for the user to mess with?

I suppose that could be done by the user – As you stated correctly, there usually isn’t a need for the generated code except for event handling. Sometimes the components need accessing to in order to retrieve values, but these could also be encapsulated in a smart way in the paret-class.

If you take a look at my X2J example application, I wrote That all in Matisse, except for the two button events which needed to be hand-implemented. Obviously, a bigger application would need a lot more of external logic, one that can easily be provided with Jars or even other packages.

About “show me all the events at once”, I suppose that could be accomplished by just viewing your code: The form’s code is nothing but the generated code (closed in some #region style area), and the events.

I do appreciate the comments. They stimulate the mind, sort of speak.