Best practice to handle nullable Integer in a Java - Flex remoting application?

Question

I have an Application consisting of a Java Server part and a Flash/Flex client, both communicate via BlazeDS. In order to have the same typed Objects on both sites, I use the GAS3 code generator (used by flex-mojos).

But now I am facing the problem of handling nullable Integers. The problem is that I have an Object (A) which contains a foreign key ID which is reference an optional Object B. – But I only send the ID to the flex client.

On the Java site it is easy:

class A {
  private Integer bFk;
  getter/setter
}

But on the flex client side, bFk is of type int. And a Flash int can not be null. So the remoting mechanism converts the Java null Integer to 0. After sending it back to the server, the Java bFk becomes 0 even on the Java side. – That is not acceptable, because I need to separate 0 and null.

My first workround is using not a Integer on the Java side, but an new Class NullAbleID, which works a bit like a wrapper/adapter, that wrap an internal int where -1 represent null (I can use -1 for null, because real id will be negative). But when I would using this it means I have to replace all Java Integer ids, by this NullAbleID class.

Because I believe I am not the first one who has this problem, I ask you for an better solution of the general question: how to represent an nullable Integer in an Java - Flex remoting scenario?

(I am aware of question: flex-null-integer, but even if it is the same problem, the question is about another subject.)

Answer 1

One idea is to use a flag value. Something like -1, or NaN.

Take a look on this bug: https://bugs.adobe.com/jira/browse/BLZ-74 - as you can see it is considered as a language limitation and is not going to be fixed by assigning NaN (as some suggested).

If you want to go with the NaN approach by yourself check Farata blog from http://flexblog.faratasystems.com/2010/01/07/how-to-keep-numeric-null-value-from-turning-into-zeros-in-blazeds. They are talking about AS->Java conversion, but looking on the comments you will find a solution for Java->AS

I would stay away from modifying all the Integers with a wrapper class, I don't like the approach - but it is a solution too.