Java: Added access object for vector of struct and vector of tables. #5233

incubus370 · 2019-03-09T10:29:47Z

This commit resolves #5223

aardappel

This generally looks great! Some suggestions..

aardappel · 2019-03-11T18:50:33Z

tests/JavaTest.java

        TestEq(test_0.a() + test_0.b() + test_1.a() + test_1.b(), 100);

+	Test.Vector test4Vector = monster.test4Vector();
+        test_0 = test4Vector.get(0);


Aren't indexing functions in Java typically called at? Or is get more typical?

get is used most often.

aardappel · 2019-03-11T18:51:38Z

tests/JavaTest.java

        TestEq(monster.testarrayoftables(0).name(), "Barney");
        TestEq(monster.testarrayoftables(1).name(), "Frodo");
        TestEq(monster.testarrayoftables(2).name(), "Wilma");
+        TestEq(monster.testarrayoftablesVector().get(0).name(), "Barney");


maybe get the vector just once, to not promote people to copy this style? :)

aardappel · 2019-03-11T18:53:28Z

tests/MyGame/Example/Stat.java

+
+    public Stat get(int j) { return get(new Stat(), j); }
+    public Stat get(Stat obj, int j) {  return obj.__assign(__indirect(vector_data_pos + j * vector_element_size, bb), bb); }
+    public int length() { return bb.getInt(vector_start_pos);}


while we're caching, could cache the length as well?

aardappel · 2019-03-11T18:55:45Z

java/com/google/flatbuffers/TableVector.java

+/**
+ * All vector of tables in the generated code derive from this class, and add their own accessors.
+ */
+public class TableVector {


There doesn't appear anything specific to tables in this class, it could easily work for a vector of doubles or whatever too. Why not add support for vectors of other types while we're at it? I'd think that the gain of only looking up the vector just once is most pronounced with iterating a scalar vector.

There are a number of conceptual issues. The current API for scalar and string vectors is different from the API for structure and table vectors in access objects:

All of these types are built-in and we need to manually create a vector object for each type of scalar (integer, fractional, byte, etc.) in com.google.flatbuffers, but not in the generated code.

The generator must add mutability methods to access objects for scalar type vectors if the corresponding flag is set. This conflicts with clause 1. The vectors of tables and structures are immutable.

Or we will have to generate code for the com.google.flatbuffers package along with the code from the schema. This will be similar to the work of the C ++ compiler with templates. The file structure of the generated code will look something like this:
foo/bar/ - classes from schema
com/google/flatbuffers/ - classes for vectors of built-in types

@aardappel The method with the generated classes will be conflicted when several schemes are used in the same project with different values of the --gen-mutable flag.

How is this problem solved in C ++ code?

But that's what I am saying: the current TableVector could actually work for other types, and would not need a copy per type.

It be fine to leave out the mutation functions for this particular class if it makes things complicated, since if someone wants to mutate, they can still use the existing functions.

Generally it be nicer to not add copies of such classes to generated code whenever possible (efficiency wise).

In C++, the Vector template always has mutation function, irrespective of whether any mutation generated code exists.

aardappel · 2019-03-11T18:56:54Z

src/idl_gen_general.cpp

      code += "    return null;\n";
      code += "  }\n";
    }
+    if (lang_.language == IDLOptions::kJava)


Would be nice to also output code for C#, if you have access to a C# compiler.

Unfortunately, I am not an expert in C # and I am not familiar with the subtleties of a language. First I propose to add an alternative API for Java. For C#, do it separately.

Fine, leave it out for now then.

incubus370 · 2019-09-16T04:55:33Z

@aardappel The work is continued. Previous comments have been fixed where possible.
Build problems are not related to changes.

aardappel

This is looking really good, excellent work. Some small issues remaining..

java/com/google/flatbuffers/DoubleVector.java

aardappel · 2019-09-16T17:22:22Z

java/com/google/flatbuffers/DoubleVector.java

+   * @param j The index from which the double value will be read.
+   * @return the double value at the given index.
+   */
+  public double get(int j) {


So we need all these copies of these typed classes because Java generics can't deal efficiently with scalars, right?

Yes, generics will generate unnecessary boxing for scalars.
There is also a problem when working with unsigned types.
Generator logic for converting to unsigned types is implemented in ByteVector, ShortVector and IntVector classes.

aardappel · 2019-09-16T17:24:43Z

java/com/google/flatbuffers/Table.java

   */
  protected int __indirect(int offset) {
-    return offset + bb.getInt(offset);
+    return __indirect(offset, bb);


This probably wasn't reused before because this function gets called so often, and it may affect speed

A static version of the __indirect method has been added to the Table class for use in vectors.
The instance method calls a static method to avoid code duplication.
Leave duplication? JIT can inline static methods to avoid the overhead of a method invocation.

static version of __union also depends on static __indirect.

Since __indirect is so core to FlatBuffers performance on Java, I'd say leave duplication to be safe, yes.

java/com/google/flatbuffers/Table.java

net/FlatBuffers/Table.cs

src/idl_gen_general.cpp

incubus370 · 2019-09-19T16:32:38Z

@aardappel PTAL

incubus370 · 2019-09-21T15:36:00Z

Branch rebased on latest master to pass all build checks =)

incubus370 · 2019-09-23T05:38:52Z

@aardappel all done

aardappel · 2019-09-23T16:22:40Z

Thanks, looks good!

…oogle#5233) * Java: Added access object for vector of struct and vector of tables. * Java: Workarounds removed when accessing the union vector.

aardappel reviewed Mar 11, 2019

View reviewed changes

incubus370 force-pushed the wp/vector_access_object branch 2 times, most recently from 3d995e8 to 3d695f7 Compare September 16, 2019 04:40

incubus370 force-pushed the wp/vector_access_object branch from 3d695f7 to 231ee2a Compare September 16, 2019 05:03

aardappel reviewed Sep 16, 2019

View reviewed changes

incubus370 force-pushed the wp/vector_access_object branch from 231ee2a to 77208c3 Compare September 17, 2019 04:44

incubus370 force-pushed the wp/vector_access_object branch 2 times, most recently from 5722b7e to e7df90f Compare September 20, 2019 06:49

incubus370 added 2 commits September 21, 2019 21:42

Java: Workarounds removed when accessing the union vector.

3afdec3

Java: Added access object for vector of struct and vector of tables.

fa00a2f

incubus370 force-pushed the wp/vector_access_object branch from e7df90f to fa00a2f Compare September 21, 2019 14:44

aardappel approved these changes Sep 23, 2019

View reviewed changes

aardappel merged commit e365c50 into google:master Sep 23, 2019

Java: Added access object for vector of struct and vector of tables. #5233

Java: Added access object for vector of struct and vector of tables. #5233

Uh oh!

Conversation

incubus370 commented Mar 9, 2019

Uh oh!

aardappel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

incubus370 commented Sep 16, 2019

Uh oh!

aardappel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

incubus370 Sep 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

incubus370 Sep 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

incubus370 commented Sep 19, 2019

Uh oh!

incubus370 commented Sep 21, 2019

Uh oh!

incubus370 commented Sep 23, 2019

Uh oh!

aardappel commented Sep 23, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

incubus370 Sep 17, 2019 •

edited

Loading

incubus370 Sep 17, 2019 •

edited

Loading