v0.9.0 Release
This release of gRPC-Java is considered beta quality.
As of this release, we expect no breaking API changes unless marked otherwise. This applies to API in packages io.grpc
, io.grpc.auth
, io.grpc.stub
, and io.grpc.protobuf
, as well as normal protobuf generated code. This does not apply to undocumented behavior; we are very likely to align gRPC-Java with the other gRPC implementations by trying harder before failing RPCs.
The codegen is not yet guaranteed forward-compatible as it uses unstable APIs. This will be resolved by 1.0. For now, you must still use the same version of the gRPC-Java protoc plugin as runtime version.
Major changes
- APIs marked with
@Internal
should not be used and those marked with@ExperimentalApi
may change in the future - Daemon threads are now used for all default thread pools
StreamObserver.onValue
has been renamed toonNext
to align with RxJava- Uses of
ChannelImpl
should now becomeManagedChannel
ManagedChannelBuilder.forAddress(String, int)
is now the preferred way of obtaining a channel builder; all transport-specific APIs do not have guaranteed API stability. Similarly, there isServerBuilder.forPort(int)
for server-side- Support for using OpenSSL via tcnative. It is preferred over using jetty-alpn. It requires OpenSSL 1.0.1 or later to be installed. gRPC will automatically fallback to NPN for OpenSSL pre-1.0.2. Please see SECURITY.md for more information
- Metadata keys and ASCII values prohibit many characters, including comma. Comma may be permitted in the future
Minor changes
- Netty and OkHttp builders support
maxMessageSize(int)
configuration - Fixes to incorrect usages of various Status codes
- Updated to protobuf 3.0.0-beta-1. Codegen supports
javanano_use_deprecated_package
, but is not using it for determining which package to generate gRPC code. That will change in the next release - Zero-handshake JWT authentication support. To use, pass in
ServiceAccountJwtAccessCredentials
. In the future will likely support auto-conversion fromServiceAccountCredentials
for use withGoogleCredentials.getApplicationDefault()
- When server completes a call with an error,
ServerCall.onComplete()
is called instead ofServerCall.onCancel()
. This was already the behavior, but the documentation now agrees - General bug fixes