Best practice for handling null-value integers in a remote Java-Flex application?

I have an application consisting of a part of Java Server and a Flash / Flex client that communicate through BlazeDS. To have the same typed objects on both sites, I use the GAS3 code generator (used by flex-mojos).

But now I am faced with the problem of handling zero integers. The problem is that I have an Object (A) that contains a foreign key identifier that references an optional object B. - But I only send the identifier to the flex client.

On a Java site, this is easy:

class A { private Integer bFk; getter/setter } 

But on the client side flex, bFk is of type int. And Flash int cannot be null. So the remote mechanism converts the Java zero integer to 0. After sending it back to the server, Java bFk becomes 0 even on the Java side. - This is unacceptable because I need to separate 0 and null.

My first workround does not use Integer on the Java side, but a new NullAbleID class that looks a bit like a wrapper / adapter that wraps an internal int where -1 represents null (I can use -1 for null because the real id will be negative) . But when I use this, it means that I have to replace all Java Integer identifiers with this NullAbleID class.

Since I believe that I am not the first to have this problem, I ask you for a better solution to the general question: how to represent a zero integer in a remote Java-Flex script?

(I know the question: flex-null-integer , but even if this is the same problem, the question is about another subject.)

+1
source share
1 answer

One idea is to use the value of the flag. Something like -1 or NaN.

Take a look at this error: https://bugs.adobe.com/jira/browse/BLZ-74 - as you can see, this is considered a language restriction and will not be fixed by the purpose of NaN (as suggested).

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

I would stay away from changing all integers with a wrapper class, I don't like this approach, but it is also a solution.

+1
source

Source: https://habr.com/ru/post/1339190/


All Articles