@nevi-me why the alias _Vector for Vector?

Same reason; conflicts with user-defined types named Vector

@nevi-me I think this change might be missing our change to the code from idl_gen_java.cpp that does the renaming of Vector to _Vector

@nevi-me this seems to be causing test failures, do you have possiblity to look at it?

@nevi-me this seems to be causing test failures, do you have possiblity to look at it?

I'll take a look today, thanks

the renaming to _Vector causes a lot of churn, breaks the API, and makes the API uglier.. not sure that's worth it over resolving a possible name clash that we haven't had complaints about so far.

@aardappel Well, rather than complain about it, we're putting together this PR :) It's not a "possible name clash" for us, it's an actual name clash, and we have deployed code where renaming our Vector type is a really expensive change to make.

What would you suggest as an alternative?

Why not just fully qualify as with Table?

"renaming our Vector type is a really expensive change to make" yes, that's just what I said about making the change on the FlatBuffers side. Except it is 1 user (you) vs potentially many FlatBuffers users affected, depending on how this collision gets fixed.

Maybe first lets understand the problem. How is your custom vector type set up in a way that it collides with these FlatBuffers Vector types, and why is that unavoidable? Agree with @bjornharrtell that in theory this should all be solvable with qualifying.

Maybe first lets understand the problem. How is your custom vector type set up in a way that it collides with these FlatBuffers Vector types, and why is that unavoidable? Agree with @bjornharrtell that in theory this should all be solvable with qualifying.

It's a table type called Vector. While some compilation errors can be resolved with full qualification the one we error we were unable to resolve is that the subclass cannot be named the same as its parent:

[ERROR] /Users/max/src/ul/ulsdk/java/src/main/java/com/urbanlogiq/ulsdk/types/generated/Vector.java:[78,23] class com.urbanlogiq.ulsdk.types.generated.Vector is already defined in package com.urbanlogiq.ulsdk.types.generated

it seems there is some overlap with this PR and #8581

it seems there is some overlap with this PR and #8581

Yes, because @aardappel said if #8581 was four PRs it would be easier to review, and there's been no other maintainer activity on it, so @nevi-me helped me split it up in the hopes that we could get these changes accepted and merged so that we don't need to keep as many local patches.

It's not so much "some overlap" as it is #8581 that's been broken up.

Thank you for the context @maxburke ! I was just going through all the open PRs and noticed that.

I'm looking at the failures here, trying to reproduce them locally. I'm seeing a lot of stray changes when I run the formatting scripts, I'm checking if maybe I have a different clang version or something.

I see this now only does what it says it does, which I think is fine.

What I missed is that I have to build flatc from the branch before running it. So I had previously pushed changes from other branches as I was inadvertently using a wrong binary.

@aardappel consider for merge

this also LGTM - since tests pass I'm going to ship it.

A bit messy that this is an exception to all the other things in the com.google.flatbuffers namespace still imported, but.. ok, doesn't hurt anyone I suppose.