* 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
If an exception occurs when performing a client request (i.e. an
IOException or a RuntimeException) then the request never completes,
even with a fail.
This happens because these types of exceptions are handled differently
in `AsyncClientBase.invokeRequest()` than other types, and the
exception is re-thrown without `fail`-ing the request leaving
client code hung.
This patch fixes the problem #358.
Signed-off-by: Alexey Morozov <morozov@gmail.com>
This is our last important Java module. There's no point to applying checkstyle to any other module in our project - it only burns CPU and causes problems.
* Use openjdk instead of oracle jdk
* Don't force Java 8 compatibility in the compiler
* Remove generated annotations from apache thrift classes
* Remove ErrorProne
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.
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.
This paves the way for Java 9 compatibility, and removes some
implementation details from consumers' compile-time classpaths. This
may break said consumers.
This is a behavior change; previously, a constant hex value would be
printed. It's not much different from before, privacy-wise, in that
missing values are still indicated; it will, however, be much easier to
debug thrifts visually.
Fixes#57.
Java names are nice, but when aggregating data from other platforms it
makes more sense to have a platform-neutral data definition... which
Thrift already provides!