Support nested tables and structs in Java as follows about flatbuffers HOT 8 CLOSED

So you want the types to store their union enum as part of their definition? The problem with that is that a type can be part of multiple unions. Also, the advantage over using the current enums doesn't seem that great to me.

from flatbuffers.

What i meant by type is not a union enum but sort of an ID assigned by the user or the compiler to tables and structs like the field id. Because if two peers are exchanging messages, then there is no way to know what type of message is contained in the data if there is no ID in the data (header).

from flatbuffers.

To distinguish multiple types of messages is what the union feature was designed for.. why not use it?

Alternatively, if you want a more free-form solution, use the file_identifier feature.

from flatbuffers.

Does the union accept structs now? or will it does?
May be i will use the file_identifier or use my own IDs.

from flatbuffers.

It does not support structs (structs are inline, so they are not size-compatible with tables).

from flatbuffers.

I think the file_id works with only one table, so how to identify other tables?
I end up using my own IDs class and removed the wrapping Message table defined above.
So my code now looks as follows

public class MessageType{
    public static final int CHALLENGE=1;
    public static final int POINT=2;
}

and use the builder as follows:

        FlatBufferBuilder fbb = new FlatBufferBuilder(100);
        Challenge.startChallenge(fbb);
        Challenge.addX(fbb, x);
        Challenge.addY(fbb, y);
        Challenge.addToken(fbb, t);
        int c = Challenge.endChallenge(fbb);
        fbb.finish(c);
        fbb.putInt(MessageTyte.CHALLENGE)

so after I call fbb.finish() I then call fbb.putInt(type) for example to add the message type;
For parsing, now i use something like:

        int t=bb.getInt(0);
        int offset=4;
        switch(t){
           case MessageType.POINT:
                Point p=Point.getRootAsPoint(bb, offset);
                processPoint(p);
                break;
           case MessageType.CHALLENGE:
                Challenge ch = Challenge.getRootAsChallenge(bb, offset)
                processChallenge(ch);
                break;
        }

The reverse writing in the ByteBuffer is a very good idea as you can see, wee can add header information without the need to copy in new buffer, and use only one write operation later to write the whole message to the socket/file. I am also planning to add the "length" of the message the same way as adding the type of message, like that i will know how many bytes to read before start parsing them, especially if the stream contains many messages.

from flatbuffers.

With file_identifier, you can simply call any number of XBufferHasIdentifier() calls to determine which type it is?

since you cannot use structs as the root of a FlatBuffer either, why not use unions as intended? that is much more compatible than your putInt solution (at least use addInt, as putInt may go out of bounds).

from flatbuffers.

Ok thanks, I will try that.

from flatbuffers.