* Expose synthetic structs for method args and result
* Make ThriftException a Struct
and make kind required (there is an "unknown" type anyways)
* Move type holders to class level in order to allow for methods to write to them
* Add runtime classes for server support
* Add server support
* Update README
* Clear type outputs at the beginning of generate()
in case the generator gets re-used
* clean up imports
* remove @JvmOverloads
* import all the things
* Remove wildcard import
* Use hand-built ClassNames instead of direct type references
in order to try to be as compatible with Kotlin Multiplatform as
possible.
* Generate server-specific interface
in a server-specific namespace instead of reusing the client interface.
This is necessary because we always want to generate a coroutine based interface for the server and never a callback based one.
* Support compilation of multiple FileSpecs as a unit
because now we generate a separate FileSpec for the server that also need the types from the "normal" FileSpec.
* Move server integration test to "normal" task
as it no longer requires the coroutine client flag to be set.
* Add license headers
* Add license to thrift test code
* Fix README
* Convert thrifty-runtime to kotlin, require Java 8
* Remove erroneous nits in KotlinCodeGenerator
* New kt files should end with a newline
* Fix artifacts from Java->Kotlin conversion, use better idioms
This adds support in generated Kotlin code for unions that have default values.
Unions are currently represented as sealed types; the default value, if present, will be a static val on the base sealed type. For example, given the following thrift:
```
union Sample {
1: string Foo = "bar";
}
```
this will emit (partial code):
```
sealed class Sample : Struct {
companion object {
@JvmStatic
val DEFAULT: Sample = Foo("bar")
}
...
class Builder {
private var value: Sample? = DEFAULT
...
}
...
class Adapter {
override fun read(protocol: Protocol): Sample {
var result: Sample = DEFAULT
...
}
}
}
```
The only point about which I'm uncertain is the Adapter.read method; it's not clear to me whether we should assume a default value if no value (or no expected value) is received; the remote end may have a different idea about what the default value is. I expect we'll never revisit this point due to the obscurity of the feature, but have called out the question as a TODO.
Fixes#303.
Prior to this commit, our generated antlr parser would happily stop midway through a file if it discovered a token it couldn't handle, such as a semicolon at the top level. This was treated as a successful parse, leading to surprising cases of missing generated structs.
Fixed here by adding `EOF` to the end of our top-level `document` definition, which is the antlr way of saying "consume all input or else it is an error".
Fixes#297
This is the simplest possible coroutine implementation. It's a thin veneer over the AsyncClientBase code, using suspendCoroutine to get at the raw Continuation object which is passed to the generated MethodCall callbacks.
We can explore more interesting implementations as coroutine I/O is finalized by JetBrains.
Fixes#211
We've missed this since the beginning because BinaryProtocol and CompactProtocol both send and receive nothing for message end. JsonProtocol, however, is sensitive to this. Adding calls to `readMessageEnd()` for both normal and exceptional results fixes things.
Instead of `--emit-kotlin`, we're adding a `--lang` option defaulting to Java. Instead of `--use-java-style-names`, we're adding `--name-style` defaulting to, well, "default", but that can also be "java" (or potentially other styles as well).
This change also attempts to infer language if it is unspecified - in this case, if `--kt-file-per-type` is specified, but `--lang` is not, we assume that `--lang=kotlin` was intended.
Fixes#209#209 envisioned a bigger revamp of the CLI, but on further thought we don't need to go to such lengths. Just providing options (instead of boolean flags) for a few params and introducing `--lang` are enough to keep the CLI reasonable.
This is good enough to get the next release out the door, but is not the end of the story for services. I still want to investigate a coroutine-based client, but that's a larger project potentially involving a kotlin-specific version of `thrifty-runtime` to support it.
We came across an issue in deserializing a bool value using compact protocol - the value always comes out false.
This PR modifies the test so that it catches this bug and fixes it.
Ben Bader
Lucas Romero
Thibault Duperron
Dino Kovač
Gabriel Ittner