v0.9.1 Release

• Hostname verification on Android, when not providing your own SSLCertificateSocketFactory
• Fix Netty transport failing to close all calls when notified that the TCP connection dropped (#1251)

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 to onNext to align with RxJava
• Uses of ChannelImpl should now become ManagedChannel
• 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 is ServerBuilder.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 from ServiceAccountCredentials for use with GoogleCredentials.getApplicationDefault()
• When server completes a call with an error, ServerCall.onComplete() is called instead of ServerCall.onCancel(). This was already the behavior, but the documentation now agrees
• General bug fixes

v0.8.0 Release

Major changes

• Deadlines are now enforced both on client / server
• Automatic connection reties with backoff
• Experimental Context API
• In-process transport added
• Implementation details moved to internal package

Minor changes

• Numerous documentation improvements
• Interceptors now fire in reverse order
• OkHTTP now has TLS on by default
• Multiple small method
• OkHttp transports now start asynchronously
• NPN Fallback for Android
• Other small code cleanups
• Lots of bug fixes

As we rapidly approach our beta release, we are cleaning up our API and organizing our code to increase maintainability. All breaking changes should have clear and available alternatives (method and class renames).

v0.7.2 Release

This is a patch release of v0.7.x that addresses two issues:

1. a server-side memory leak when using ALPN (#598 via 492128e).
2. Fix ALPN for OkHttp transport on Android versions older than 5.0.

v0.7.1 Release

This is a patch release of v0.7.0 that fixes #504 (via cdd81d2). The patch addresses a race condition where multiple Netty transports can be created by the same builder, resulting in an unsharable handler being added to multiple Netty pipelines. In addition, better error handling has been added to the bootstrap of TLS pipelines in order to detect errors that occur early on in protocol negotiation that may have previously been missed.

v0.7.0 Release

First tagged release of gRPC-Java with artifacts and dependencies on Maven Central, complete with binary protoc plugin.

gRPC-Java is considered alpha quality and does not yet guarantee API-stability.