Client: go
When a thrift file includes 2 or more other thrift files, and those
included thrift files do not have explicit go namespaces defined, the
current import dedup logic would wrongly use their empty namespace and
skip the second one, while the real import namespace should be inferred
from the filename.
Client: py
When no fields are present, we don't get the special constructor that
uses __setattr__ to avoid these checks. So the default constructor sets
message normally and triggers the anti-mutation tripwires.
Client: netstd
Patch: Jens Geyer
The recommended pattern matching expression \"that is not SomeType\" requires C#9/net5.0 but we still want to support earlier versions (.NET Core 3.1 is LTS until 2022-DEC-03)
Client: go
When a thrift file includes 2 or more other thrift files, and those
included thrift files do not have explicit go namespaces defined, the
current import dedup logic would wrongly use their empty namespace and
skip the second one, while the real import namespace should be inferred
from the filename.
Client: py
When no fields are present, we don't get the special constructor that
uses __setattr__ to avoid these checks. So the default constructor sets
message normally and triggers the anti-mutation tripwires.
Patch: Juan Cruz Viotti
This closes#2312
I'm having problems following the var int explanation from the Compact
Protocol spec. Here is an attempt to clarify it with more precise
encoding steps and with an example.
I'm also mentioning, for completeness, that the formal name of such
variable-length integer encoding is Unsigned LEB128 (Unsigned Little
Endian Base-128).
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
Patch: Juan Cruz Viotti
This closes#2313
It might not be obvious from the existing description. I had to run some
experiments to double-check it and this might save some time to the next
interested reader.
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
Client: Java
Patch: Christopher Tubbs
This closes#2325
* Enforce Java 8 compatibility using the new `--release` flag introduced
in JDK9, so that all generated bytecode follows Java 8 strict
compatibility, even when building with newer JDK versions (9 or later)
(this fixes NoSuchMethodError with ByteBuffer, and other potential
incompatibilities in bytecode generation that would make the code
unable to run on a Java 8 JRE)
* Also strictly enforce the JDK version used to build the project by
ensuring it is at least version 1.8, and will fail fast when building
the Java libraries if this condition is not met.
