While playing with fwt my JVM crashed yesterday. I suspect it happened because I subclassed 'BorderPane' (to set a default border, insets and bg color in the constructor).

Without adding contents this subclass shows as a big black square (not the bg color), and when setting the contents to a 'Tree' (I haven't tried anything else yet) the JVM crashed. This is the error that I got:

ERROR: setting public final fan.fwt.Prop$Custom fan.fwt.TreePeer.selected

The stack trace showed a (Java) NullPointerException as the root cause. Oddly enough, the error mentions the 'TreePeer', while I never had any problems when I wrapped the same 'Tree' in a regular 'BorderPane'.

Was this caused by subclassing 'BorderPane'? Didn't it create its native peer or something?

EDIT: I changed the title of this issue.

I got the same thing yesterday while working on my data binding stuff. I noticed Table.refreshAll would throw an NPE if the table wasn't yet realized in the UI. I put a boundary condition that required table.parent != null before calling refreshAll and that fixed the problem for me.

Turns out it was something else entirely. I intended to pass a 6-digit color to Border.fromStr, but I forgot the # symbol:

Border("778899")

instead of

Border("#778899")

Border of course took this as a very large width. On a single instance this simply painted the component black (being the very wide border), but on multiple instances this caused a crash. This looks to me as a memory problem, though I don't see why a wide border should use any more memory than a thin border. Does it perhaps paint the entire border on an off-screen location, and then copy just the visible clip to the screen?

This probably pushes down in the Graphics implementation of Java2D and/or OS. BorderPane will try to use a stroke width of 7778899 here which based on a quick google search sounds like it can lead to problems.