There is some confusion regarding the way forward for using Protobuf on Android with Java. Should one be using JavaNano or Lite? Right till the release of 3.0, the recommended option seemed to be JavaNano and then something suddenly switched.
The only hint is this line
Since Protobuf 3.0.0, protobuf-lite is the recommended Protobuf library for Android
from https://github.com/google/protobuf-gradle-plugin
On the other hand, https://developers.google.com/protocol-buffers/docs/proto3 does not seem to suggest nano over lite or vice versa.
It would be great if there is guidance and a set of how-to's (why's if possible) delivered for Android Java. It would greatly benefit the community. There is information present, but is disparate and sometimes not updated, which regularly confuses folks using Protobuf. Case in point #956 which got duped in #2479 .
If there is such information already present, could you please point us to it.
I think we have never officially released nano. So lite is the only thing we support.
@anandolee Could you please reopen this issue?
@TeBoring I am not sure if I understand the idea behind "officially releasing" nano. I am also not sure if lite is the only thing that is supported. I base this on the following:
The following page is the official documentation for Protocol Buffers v3
https://developers.google.com/protocol-buffers/docs/proto3
Doing a simple search on this page for "nano" should throw up results for JavaNano. In fact, there is this snippet
--javanano_out generates JavaNano code in DST_DIR.
The JavaNano code generator has a number of options you can use to customize the generator
output: you can find out more about these in the generator README.
JavaNano generated code reference is coming soon!
The README points to https://github.com/google/protobuf/tree/master/javanano, which has the following content
JavaNano is a special code generator and runtime library designed
specially for resource-restricted systems, like Android. It is very
resource-friendly in both the amount of code and the runtime overhead
So, I would appreciate if there is guidance from the Protocol Buffers team with respect to Android Java.
Lite is recommended for Android
We are in general deprecating nano in favor of lite for mobile usages. And we have no plan to further improve nano runtime.
We have just updated the doc in README that "Nano is no longer supported by protobuf team. We recommend Android users to use protobuf lite runtime instead.":
https://github.com/google/protobuf/blob/master/javanano/README.md
Danke @anandolee for the helpful context.
Would it be possible to please update https://developers.google.com/protocol-buffers/docs/proto3 with the Nano deprecation message?
On a side note, it is easier to understand things from the outside when there is communication and guidance in terms of future direction.
I'm out of the loop with Java, but until reading the protobuf docs I'd never heard of JavaLite or JavaNano, and googling for them isn't very elucidating (this issue was one of the top results, though). I agree with Brahmasmi, though, that the docs should be updated to reflect deprecation of nano. They still say "For JavaNano, the compiler output is similar to Java but there are no Builder classes." and this is nearly a year after @anandolee's message. 🤷♂️
I'm reopening this issue while I'm getting rid of every mentioning of javanano in our docs.
About the question of nano vs. lite, nano has never been well supported by protobuf-team. Internally we are actually migrating teams from nano to lite. In the opensource world, the lite support is a bit lacking (not so much better than nano), but we do plan to improve opensource lite support in Q2 this year (new releases, better documentation, and tooling support to achieve optimal code size savings).
Closing as references to javanano have been removed from protobuf developer guide.
This too requires change? It still says to go for nano in case of Android.
That too is out of date. I will file a bug on the Android docs team.
Most helpful comment
About the question of nano vs. lite, nano has never been well supported by protobuf-team. Internally we are actually migrating teams from nano to lite. In the opensource world, the lite support is a bit lacking (not so much better than nano), but we do plan to improve opensource lite support in Q2 this year (new releases, better documentation, and tooling support to achieve optimal code size savings).