Good morning everyone. I have an immediate pressing problem I hope you can help with. I am attempting to use Flatbuffers over JeroMQ in a Java 8 only environment. I have code that works in a Java 9+ environment, but in Java 8 I get the exception below. Does anyone know how to fix this (other than obvious use Java 9 or 10)? For example, is there a flatc setting to generate Java 8 compatible classes?
Exception in thread "main" java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
at com.google.flatbuffers.FlatBufferBuilder.createString(FlatBufferBuilder.java:605)
at jeromq_and_flatbuffers.io.MonsterIO.writeTo(MonsterIO.java:54)
at jeromq_and_flatbuffers.io.MonsterIO.writeTo(MonsterIO.java:1)
at jeromq_and_flatbuffers.core.MonsterPublisher.sendMessage(MonsterPublisher.java:80)
at jeromq_and_flatbuffers.core.MonsterPublisher.run(MonsterPublisher.java:104)
at jeromq_and_flatbuffers.core.Main.lambda$0(Main.java:46)
at java.util.Optional.ifPresent(Optional.java:159)
at jeromq_and_flatbuffers.core.Main.main(Main.java:46)
Hi - I have a usage questions:
I have a flatbuffers structure representing a tree (SQL Plan).
I would like to add some methods to the generated classes, e.g.:
table Join { size:int; }
would like to add a method:
bool Join::isLargerThan100(); // returns true if size>100
I am not sure if my request makes sense or how to implement that.
Is there some support from flatbuffers itself or some recommended way of doing this?
Is it allowed to derive from class Join (or rather use composition) with my custom class and add functions and add a special desieralizetion pass of the flatbuffers buffer?
I guess it's a bit of a unique scenario in our case... the issue is we have an old type that has two possible fields (ie: explicitly named field1 and field2) , and we're replacing it with a new type that has n-possible fields (ie: a list). the old data is still valid as the new ones as on load we deserialize field1 and field2 into a 2-element list, but we want to not write the old type anymore.
the current solution is to name the old field "deprecated_old_field_do_not_use" which I think kind of gets the point across ( :) ), and I think I can live with, but I was thinking it would be good to make sure that no builders were available for it.