Examples and android projects were left unchanged. They can be changed
later.
No plugin versions were changed, to make this as non-functional of a
change as possible. Upgrading Gradle to 5.6 was necessary for
pluginManagement in settings.gradle.
* compiler: Use 'SERVICE_NAME' instead of duplicated '$Package$$service_name$'
* compiler: Align indentation
* Fix typo
* Add modified golden files and all re-generated code to meet Travis CI and Windows build requirements
See PR #5943
* Polishing
The 3rd-party rules_proto project is referencing our compiler directly
and not using our java_grpc_library. This target is fine for them to
use (although we'd prefer using our java_grpc_library), but most users
shouldn't be touching it.
Related to #5942 and #5947
This removes the "java_import to work around error with android_binary"
hack; see the b/78647825 references to see the really important parts.
But in general using a toolchain cleans up the code considerably and
allows us to reduce the visibility of our protoc plugin. It also is
useful to enable using aspects in the future to avoid using
make_non_strict() which would improve compilation speed avoid avoid many
unnecessary rebuilds.
This is an export of cl/229763103 and brings external up-to-sync with
internal.
For Bazel, we upgrade to protobuf 3.6.1.2 and javalite HEAD to fix
incompatibilities in newer Bazel releases.
compiler/Dockerfile is unused, so it was removed instead of being updated.
protoc no longer includes codegen for nano, so we remain on the older protoc
any time nano is used.
Protobuf now requires C++11 when compiling, so windows was swapped to
VC 14.
It appears everything was already working on Java 11, except
build-specific and testing issues. Updating to Netty 4.1.30 (#4940)
probably fixed the last true Java 11 incompatibility.
Fixes#4933
This PR adds an automatic gradle format checker and reformats all the *.gradle files. After this, new changes to *.gradle files will fail to build if not in good format, just like checkStyle failure.
The new jmh plugin fixes a warning for the newer version of Gradle.
The new AppEngine plugin still produces a warning, but updating it
anyway so people know that upgrading the plugin doesn't fix the problem.
The new android-maven plugin fixes a build problem with the newer
Gradle.
The Visual Studio fixes were necessary starting ~4.4.
https://github.com/gradle/gradle-native/issues/34#issuecomment-335222096
describes the change in behavior.
There's nothing immediately being used as part of this update. It's just
to keep us current and to get us over that Visual Studio change hump.
This change puts the compiler test.proto file in a directory that matches it's path. The current proto package has a namespace collision with the grpc.testing proto in interop-testing. Thus, this PR:
* change the package of test.proto to be grpc.testing.compiler
* moves the test.proto into the matching grpc/testing/compiler/test.proto path
* updates the generated code.
previously `Import` fails because it gets turned into a method named
`import`. This PR makes the method be named `import_`, everything else
stays the same, such as the name in the method descriptor.
Note: `iMport` or `iMPORT` or any variation of capitalizations that is
not `Import` always worked. `Import` gets translated into `import`
because of our attempts to camel case the names.
Previously if protobuf-generated code triggered ErrorProne we'd have to disable
the failing check for all code in that task. With -XepExcludedPaths we can
disable the ErrorProne-checking just for protobuf. Note that we continue using
ErrorProne on our generated code. Also note this only applies to ErrorProne
checks; JDK checks still require task-level disabling.
This moves away from the global String-based Span name registry which
is not as flexible as we desire.
Also renamed the option name to be more accurate. This is not
API-breaking because the origianl addition to MethodDescriptor and
code-gen didn't make it into the 1.7.0 release.
* MethodDescriptor is lazy loaded, so protobuf loading only happens on demand. This also means tracing registration happens on demand.
* The names of the getters all being with `method`. This makes it harder for autocomplete to pick them up.
* A new field is used, which matches the getter name. Rather than make the new-getters reference the old-fields, make the old-fields reference the new getters. This makes removal of the old-fields a simple operation.
* The getters may not be inlineable, but thats an easy fix if it ends up being a problem. Not worth premature optimization (but is worth future work).
The expected timeline for this is adding this to the 1.8 cut, and deprecating the old-fields. They will be removed in 1.9.
This is a more favorable approach than #3467. Doing the registration
in MethodDescriptor should allow us to deregister in case the
generated stub and its MethodDescriptors are garbage-collected
routinely, e.g., if they are loaded by a separate ClassLoader.
This bump changelist is applied a bit late with respect to the
1.6.0 branch cut. Look at the 1.6.0 to see the source of truth of
where it was cut. Do not assume it is the commit that precedes
this one.
This fixes sign-compare and maybe-unintialized. An unused-value warning
remains.
I changed LogHelper to always call abort so the compiler would know the
method does not return, which fixed the maxbe-uninitialized warning.
Bazel third party dependencies are specified in repositories.bzl which
gives the consumer the ability to opt-out of any dependencies they use
directly in their own project.
Fixes#2756
The code uses std::back_insert_iterator which is part of the <iterator>
header. The header is not included though.
We (bazel) noticed the build failing on Windows when using the Visual Studio
C++ compiler.
ErrorProne provides static analysis for common issues, including
misused variables GuardedBy locks.
This increases build time by 60% for parallel builds and 30% for
non-parallel, so I've provided a way to disable the check. It is on by
default though and will be run in our CI environments.
not necessary to synchronze every time calling
getServiceDescriptor(), if the descriptor has been created already;
go with the double-checked locking idom
The 32-bit windows grpc codegen built with protobuf 3.0.2 depends on
USER32.DLL, while the previous release built with protobuf 3.0.0 didn't.
Both protobuf and grpc codegen are built under msys2-mingw32.
"objdump -x libprotobuf-10.dll | grep DLL" also shows the USER32.DLL
dependency being brought by protobuf:
3.0.0
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: zlib1.dll
DLL Name: libgcc_s_dw2-1.dll
DLL Name: libstdc++-6.dll
3.0.2
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: USER32.dll
DLL Name: zlib1.dll
DLL Name: libgcc_s_dw2-1.dll
DLL Name: libstdc++-6.dll
While unexpected, USER32.dll is shipped with Windows so having such
dependency shouldn't cause any trouble.
Also removed warnings about protoc version matching runtime, since this
is no longer supposed to be a problem (starting with 3.0.0-beta-4) and
all our tests ran fine when using protoc 3.0.2 with protobuf runtime
3.1.0.
Fixes#2316
core: adds @Nullable Object getAttachedObject() to ServiceDescriptor
compiler: Plumbing necessary to access proto file descriptors via
the reflection service
protoc no longer builds in 3.0.0 because auto-download of the gmock zip
now fails. 3.0.2 has a fix to autogen:
bba446bbf2
All that was strictly necessary was to update .travis.yml and
buildscripts/, but it helps our sanity to keep the rest of the protobuf
versions in sync. Lite is left on its existing version, because it did
not see a bump of neither the java library nor the protoc plugin.
This reduces the number of methods gRPC brings in by ~450, which is
substantial. Each application will see different numbers though,
depending on their usage and their other dependencies.
A very rough (under) counting for number of methods included because of
gRPC in android-interop-test is 2746, and that is reduced to 2313 (-433)
by this change. That count includes grpc, guava, okhttp, okio, and nano.
The actual reduction of methods is 447, with the discrepency due to
reduction of methods in java.util and java.lang. Of the 433 removed
methods, 377 are from com.google.common.collect and 61 from
com.google.common.base. The removal costed an increase of 5 methods
(total 1671) within io.grpc itself.
Protobuf-lite since beta-4 is now more of a fork than a subset of
protobuf-java, which may cause us problems later since lite API is not
stable. Also, lite-generated code may now depend on APIs only in
protobuf-lite, so our users must depend on the protobuf-lite runtime.
Having all our users explicitly override the dependency is bothersome to
them and can easily only expose problems only after we do a release.
So now we are doing the dependency overriding; most users should "just
work" and pick up the correct protobuf artifact. I've confirmed the
exclusion is listed in the grpc-protobuf pom and "gradle dependencies"
and "mvn dependency:tree" do not include protobuf-lite for the examples.
Vanilla protobuf users are most likely to experience any breakage, which
should detect problems more quickly since we use protobuf-java more
frequently than protobuf-lite during development.
protobuf-lite does not include pre-generated code for the well-known
protos, so users will need to generate them themselves for the moment
(google/protobuf#1889).
Note that today changing deps does not noticeably reduce the method code
for our users, since ProGuard already is stripping most classes. The
difference in output is only a reduction of 3 classes and 6 methods for
the android example.
partially resolving #1469
The added option for java_plugin `enable_deprecated` is `true` by default in `java_plugin.cpp`, so the generated code for `TestService.java` (`compiler/build.gradle` not setting this option) has all deprecated interfaces and static bindService method.
`./build.gradle` and `examples/build.gradle` set this option explicitly to `false`, so all the other generated classes do not have deprecated code.
Will set `enable_deprecated` to `false` by default in future PR when we are ready.
first step to address issue #1469:
- leave and deprecate interfaces in codegen
- introduce `ServiceImplBase`,
- `AbstractService` is deprecated and extends `ServiceImplBase`
- static `bindService()` is deprecated
This allows us to play with zero-copy and proto3 support for lite.
Unfortunately, it introduced some warnings, so deprecated warnings are
now ignored for benchmarks and interop-testing.
This reverts commit 3df1446deb.
The commit was adding to the difficulty of integration for testing. By
itself it isn't bad, so this is a temporary revert until the many other
commits are absorbed and then it will be reapplied.
This does have a manual edit for ClientCallsTest.
This now catches a few more places we needed -Xlint:-options.
InProcessSocketAddress is technically already in our stable API, so I
maintained its current serialVersionUID.
'nano=true' still works, but any value is now ignored. This is to align
with our lite flag, but also just because It's Cleaner.
Note that this is counter to what javanano does. Javanano requires all
flags have a value and uses true/false for many values.
Lite already worked by using the protobuf project, but would bring in
extra dependencies that are not intended to work with lite. Although
protobuf is not yet providing a lite package on Maven Central, we will
be able to swap to it once it is available.
There isn't any new original code in the Java portion, except for a new
overload in ProtoUtils that accepts Message instead of MessageLite.
Depending on Message in ProtoUtils allows us to support extra features
out-of-the-box without any changes to the generated code. For example,
JSON encoding could be supported in this way if Marshaller is enhanced.
However, now codegen must be aware of Lite in order to choose with Util
class to use. That is new code.
This requires that all nano protos have .nano in their package name. The
support is expected to be removed from protobuf soon, since using the
deprecated package name causes problems.
check-artifact.sh was broken by the update to Gradle 2.10. We think the
update to Gradle 2.8 caused the POM to start being generated, but this
now fixes it to have the correct contents.
Using addFilter _disables_ the normal POM, so we use setFilter instead.
Fixes#1360
This reduces the necessary number of threads in the application executor
and provides a small improvement in latency (~15μs, which is normally in
the noise, but would be a 5% improvement).
Benchmark (direct) (transport) Mode Cnt Score Error Units
Before:
TransportBenchmark.unaryCall1024 true INPROCESS avgt 10 1566.168 ± 13.677 ns/op
TransportBenchmark.unaryCall1024 false INPROCESS avgt 10 35769.532 ± 2358.967 ns/op
After:
TransportBenchmark.unaryCall1024 true INPROCESS avgt 10 1813.778 ± 19.995 ns/op
TransportBenchmark.unaryCall1024 false INPROCESS avgt 10 18568.223 ± 1679.306 ns/op
The benchmark results are exactly what we would expect, assuming that
half of the benefit of direct is on server and half on client:
1566 + (35769 - 1566) / 2 = 18668 ns --vs-- 18568 ns
It is expected that direct=true would get worse, because
SerializingExecutor is now used instead of
SerializeReentrantCallsDirectExecutor plus the additional cost of
ThreadlessExecutor.
In the future we could try to detect the ThreadlessExecutor and ellide
Serializ*Executor completely (as is possible for any single-threaded
executor). We could also optimize the queue used in ThreadlessExecutor
to be single-producer, single-consumer. I don't expect to do those
optimizations soon, however.
This reduces the number of classes defined, which reduces memory usage.
It also reduces the number of methods defined, which is important
because of the dex limit.
This should have virtually zero performance degradation because the
contiguous switch uses tableswitch bytecode.
This reduces the number of classes defined, which reduces memory usage.
It also reduces the number of methods defined, which is important
because of the dex limit.
This should have virtually zero performance degration because the
contiguous switch uses tableswitch bytecode.
ARG_IN_ and ARG_OUT_ are prefixes as otherwise there could be a name
collision with an oddly-named method. Since the other fields are
prefixed with METHOD_ they can't collide.
There is no need to use ServerMethodDefinition in codegen. The create()
method itself could be helpful to a dynamic HandlerRegistry
implementation, so we won't remove it.
This reduces the amount of logic built into the generated code. If we
swap to an alternative form of decoding we should have greater ability
to adapt the existing API to make use of the new one. Previously most
changes would require duplicating all the nano marshalling code.
Eric Anderson
Jihun Cho
Chengyuan Zhang
ZHANG Dapeng
Jean de Klerk
liym
Adam Liddell
Kun Zhang
Carl Mastrangelo
Thomas Broyer
elandau
zpencer
jbingham-google
Eric Gribkoff
Lukasz Janyst
Lukasz Strzalkowski
Simon Horlick
Jakob Buchgraber
Łukasz Strzałkowski
Nishidha
Louis Ryan
nmittler
Kun Zhang
Xudong Ma
David P. Baker