Re: [protobuf] setting fields in repeated messages rise exception

['Adam Cozzette' via Protocol Buffers]

My guess is that you're somehow mixing new generated code with an older
runtime library. That Internal.checkNotNull method was introduced earlier
this year, so older versions of the runtime don't have it. I'm surprised
that you got a NoSuchMethodError instead of a compile-time error, though.

On Sun, Dec 17, 2017 at 12:18 PM,  wrote:

> message Word{
> int32  id = 1;
> string t1 = 2;
> string t2 = 3;
> bytes  s1 = 4;
> repeated WordSample ws= 5;
>
> }
>
> message WordSample{
> int32  id_word  = 1;
> string t1   = 2;
> string t2   = 3;
> bytes  s1   = 4;
> }
>
>
> var k=Word.newBuilder()
> k.id=1
> k.t1="t1"
> k.t2="t2"
> k.addWs(WordSample.getDefaultInstance())
> k.addWs(WordSample.getDefaultInstance())
> k.addWs(WordSample.getDefaultInstance())
>// k.build()
>
>k.getWsBuilder(1).setT2("try to change")
>
>
>// java.lang.NoSuchMethodError: 
> com.google.protobuf.Internal.checkNotNull(Ljava/lang/Object;)Ljava/lang/Object;
>
>
>I need to create a Message with a repeated Message within, the question is 
> that I need to set some fields at a diferent moments, thus I have to acces 
> the inner message and set the field.
>But it simply launches the above exception, it really looks like a bug, 
> why would you ever have getBuilder properties with a setter for if you can't 
> set anything ?
>
>latest protobuf in kotlin thanks in advance
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Is protobuf3 a superset of protobuf2?

['Adam Cozzette' via Protocol Buffers]

Yes, we are planning on supporting proto2 pretty much forever. Within
Google we have a huge amount of code using proto2 and for the most part
we're not attempting to migrate existing code to proto3. Language support
is one reason to go with proto3, but it's also simpler and more convenient
for working with JSON.

On Tue, Dec 19, 2017 at 12:13 PM, Josh Humphries 
wrote:

> Adam,
> I understand there is no *current* plan to deprecate proto2. But is it
> really expected to be supported forever?
>
> If that's the case, I suppose the only reason to choose proto3 over proto2
> (if you happen to want the features and semantics of proto2) might be that
> not all languages/runtimes have support for proto2. Though I thought this
> was a short/medium-term issue. If all languages/runtimes eventually support
> both, it seems like a strange decision to continue supporting both
> indefinitely.
>
>
> 
> *Josh Humphries*
> jh...@bluegosling.com
>
> On Tue, Dec 19, 2017 at 2:23 PM, Adam Cozzette 
> wrote:
>
>> Actually we have no plans to deprecate proto2 and we are still actively
>> developing it, so you can really choose either one without having to worry
>> about support going away.
>>
>> On Sat, Dec 16, 2017 at 11:42 AM, Josh Humphries 
>> wrote:
>>
>>> I think proto3 was intended to be simpler -- an evolution of protobuf in
>>> a direction that is more refined and elides superfluous features.
>>> Eventually (though not likely any time soon), support for proto2 will go
>>> away.
>>>
>>> The main omission in proto3 that I personally felt strongly about was
>>> the lack of preserving unknown fields. But that functionality has been
>>> restored for many languages/runtimes in 3.5 (and coming soon, hopefully,
>>> for Go and the others).
>>>
>>> All of the other omissions in proto3 have alternate
>>> solutions/work-arounds that aren't baked into the language (like wrapper
>>> types and Any), which shows that these features didn't truly need to be
>>> language features to begin with. So it allows the language itself to remain
>>> simple, which means libraries/tooling are simpler to build on top.
>>>
>>> So a big advantage of proto3 is simplicity (and for some
>>> languages/runtimes, that will translate into improved performance). And
>>> another advantage is future compatibility (since, in all likelihood, proto2
>>> will eventually go away.)
>>>
>>>
>>> If creating new files, it makes sense to use proto3. If you already have
>>> a corpus of proto2 files, a reasonable migration path forward is to start
>>> evolving them to proto3 (or, if the languages/runtimes you use don't yet
>>> preserve unrecognized fields, wait for that functionality to be fully
>>> implemented everywhere and then start evolving).
>>>
>>>- Make required fields optional. Required fields have always been
>>>dangerous. If a field is required in your protocol, it can be enforced in
>>>application code instead of in the de-serialization logic of the protobuf
>>>runtime.
>>>- Use Any instead of extensions. An extension range can generally be
>>>replaced with a repeated Any field. Extensions with scalar types will 
>>> have
>>>to be "boxed" into single-field messages.
>>>- Use wrapper types for scalar fields where absence must be
>>>distinguishable from zero.
>>>- Usages of default values can be changed to use wrapper types and
>>>application logic that decides non-zero values to use when the field is 
>>> not
>>>present.
>>>- Groups should be replaced with nested messages.
>>>
>>> Once a file is no longer using any proto2 features, it can be changed to
>>> proto3 syntax. Unfortunately, there is not yet a way to incrementally move
>>> to proto3. Once you change the syntax of the file, the generated code will
>>> change, and all clients of that generated code must be changed atomically
>>> in order to compile (at least for languages/runtimes where generated code
>>> for the two syntaxes is materially different/incompatible). I would hope
>>> that this is something that will be addressed in future versions of
>>> protobuf, to facilitate migrations away from proto2.
>>>
>>>
>>> 
>>> *Josh Humphries*
>>> jh...@bluegosling.com
>>>
>>> On Sat, Dec 16, 2017 at 2:17 PM, ajcurtis84 
>>> wrote:
>>>
 Thank you everyone for all the great input!

 Based on this discussion, what is the advantage of using proto3? It
 appears that proto2 is more feature rich. JSON isn't a compelling 
 reason

 Thanks

 --
 You received this message because you are subscribed to the Google
 Groups "Protocol Buffers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to protobuf+unsubscr...@googlegroups.com.
 To post to this group, send email to protobuf@googlegroups.com.
 Visit this group at https://groups.google.com/group/protobuf.
 For more 

Re: [protobuf] Is protobuf3 a superset of protobuf2?

[Josh Humphries]

Adam,
I understand there is no *current* plan to deprecate proto2. But is it
really expected to be supported forever?

If that's the case, I suppose the only reason to choose proto3 over proto2
(if you happen to want the features and semantics of proto2) might be that
not all languages/runtimes have support for proto2. Though I thought this
was a short/medium-term issue. If all languages/runtimes eventually support
both, it seems like a strange decision to continue supporting both
indefinitely.



*Josh Humphries*
jh...@bluegosling.com

On Tue, Dec 19, 2017 at 2:23 PM, Adam Cozzette  wrote:

> Actually we have no plans to deprecate proto2 and we are still actively
> developing it, so you can really choose either one without having to worry
> about support going away.
>
> On Sat, Dec 16, 2017 at 11:42 AM, Josh Humphries 
> wrote:
>
>> I think proto3 was intended to be simpler -- an evolution of protobuf in
>> a direction that is more refined and elides superfluous features.
>> Eventually (though not likely any time soon), support for proto2 will go
>> away.
>>
>> The main omission in proto3 that I personally felt strongly about was the
>> lack of preserving unknown fields. But that functionality has been restored
>> for many languages/runtimes in 3.5 (and coming soon, hopefully, for Go and
>> the others).
>>
>> All of the other omissions in proto3 have alternate
>> solutions/work-arounds that aren't baked into the language (like wrapper
>> types and Any), which shows that these features didn't truly need to be
>> language features to begin with. So it allows the language itself to remain
>> simple, which means libraries/tooling are simpler to build on top.
>>
>> So a big advantage of proto3 is simplicity (and for some
>> languages/runtimes, that will translate into improved performance). And
>> another advantage is future compatibility (since, in all likelihood, proto2
>> will eventually go away.)
>>
>>
>> If creating new files, it makes sense to use proto3. If you already have
>> a corpus of proto2 files, a reasonable migration path forward is to start
>> evolving them to proto3 (or, if the languages/runtimes you use don't yet
>> preserve unrecognized fields, wait for that functionality to be fully
>> implemented everywhere and then start evolving).
>>
>>- Make required fields optional. Required fields have always been
>>dangerous. If a field is required in your protocol, it can be enforced in
>>application code instead of in the de-serialization logic of the protobuf
>>runtime.
>>- Use Any instead of extensions. An extension range can generally be
>>replaced with a repeated Any field. Extensions with scalar types will have
>>to be "boxed" into single-field messages.
>>- Use wrapper types for scalar fields where absence must be
>>distinguishable from zero.
>>- Usages of default values can be changed to use wrapper types and
>>application logic that decides non-zero values to use when the field is 
>> not
>>present.
>>- Groups should be replaced with nested messages.
>>
>> Once a file is no longer using any proto2 features, it can be changed to
>> proto3 syntax. Unfortunately, there is not yet a way to incrementally move
>> to proto3. Once you change the syntax of the file, the generated code will
>> change, and all clients of that generated code must be changed atomically
>> in order to compile (at least for languages/runtimes where generated code
>> for the two syntaxes is materially different/incompatible). I would hope
>> that this is something that will be addressed in future versions of
>> protobuf, to facilitate migrations away from proto2.
>>
>>
>> 
>> *Josh Humphries*
>> jh...@bluegosling.com
>>
>> On Sat, Dec 16, 2017 at 2:17 PM, ajcurtis84  wrote:
>>
>>> Thank you everyone for all the great input!
>>>
>>> Based on this discussion, what is the advantage of using proto3? It
>>> appears that proto2 is more feature rich. JSON isn't a compelling reason
>>>
>>> Thanks
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Protocol Buffers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to protobuf+unsubscr...@googlegroups.com.
>>> To post to this group, send email to protobuf@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/protobuf.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to protobuf+unsubscr...@googlegroups.com.
>> To post to this group, send email to protobuf@googlegroups.com.
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this 

Re: [protobuf] Is protobuf3 a superset of protobuf2?

['Adam Cozzette' via Protocol Buffers]

Actually we have no plans to deprecate proto2 and we are still actively
developing it, so you can really choose either one without having to worry
about support going away.

On Sat, Dec 16, 2017 at 11:42 AM, Josh Humphries 
wrote:

> I think proto3 was intended to be simpler -- an evolution of protobuf in a
> direction that is more refined and elides superfluous features. Eventually
> (though not likely any time soon), support for proto2 will go away.
>
> The main omission in proto3 that I personally felt strongly about was the
> lack of preserving unknown fields. But that functionality has been restored
> for many languages/runtimes in 3.5 (and coming soon, hopefully, for Go and
> the others).
>
> All of the other omissions in proto3 have alternate solutions/work-arounds
> that aren't baked into the language (like wrapper types and Any), which
> shows that these features didn't truly need to be language features to
> begin with. So it allows the language itself to remain simple, which means
> libraries/tooling are simpler to build on top.
>
> So a big advantage of proto3 is simplicity (and for some
> languages/runtimes, that will translate into improved performance). And
> another advantage is future compatibility (since, in all likelihood, proto2
> will eventually go away.)
>
>
> If creating new files, it makes sense to use proto3. If you already have a
> corpus of proto2 files, a reasonable migration path forward is to start
> evolving them to proto3 (or, if the languages/runtimes you use don't yet
> preserve unrecognized fields, wait for that functionality to be fully
> implemented everywhere and then start evolving).
>
>- Make required fields optional. Required fields have always been
>dangerous. If a field is required in your protocol, it can be enforced in
>application code instead of in the de-serialization logic of the protobuf
>runtime.
>- Use Any instead of extensions. An extension range can generally be
>replaced with a repeated Any field. Extensions with scalar types will have
>to be "boxed" into single-field messages.
>- Use wrapper types for scalar fields where absence must be
>distinguishable from zero.
>- Usages of default values can be changed to use wrapper types and
>application logic that decides non-zero values to use when the field is not
>present.
>- Groups should be replaced with nested messages.
>
> Once a file is no longer using any proto2 features, it can be changed to
> proto3 syntax. Unfortunately, there is not yet a way to incrementally move
> to proto3. Once you change the syntax of the file, the generated code will
> change, and all clients of that generated code must be changed atomically
> in order to compile (at least for languages/runtimes where generated code
> for the two syntaxes is materially different/incompatible). I would hope
> that this is something that will be addressed in future versions of
> protobuf, to facilitate migrations away from proto2.
>
>
> 
> *Josh Humphries*
> jh...@bluegosling.com
>
> On Sat, Dec 16, 2017 at 2:17 PM, ajcurtis84  wrote:
>
>> Thank you everyone for all the great input!
>>
>> Based on this discussion, what is the advantage of using proto3? It
>> appears that proto2 is more feature rich. JSON isn't a compelling reason
>>
>> Thanks
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to protobuf+unsubscr...@googlegroups.com.
>> To post to this group, send email to protobuf@googlegroups.com.
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Protobuf and Golang: How to generate a map string interface using proto3?

[jefft]

To be clear, what I meant by: "a *proto3* package cannot reference another 
*proto3* package"

To complete that statement, "within the same repository".

So, *I am not sure if I can do a local import of a proto3 package*.

There are multiple Protobuf packages within this repository, and each 
package is associated with a specific golang microservice.

protobuf

├── foo

│   ├── task_jobs.pb.go

│   ├── task_jobs.proto

│   ├──service.pb.go

│   └──service.proto

└── bar

  ├── service.pb.go

  └──  service.proto

services

├── foo

│   └──microservice Go code

└── bar
  └── microservice Go code


On Tuesday, December 19, 2017 at 10:01:58 AM UTC-8, je...@tune.com wrote:
>
> Hi, I am new in using Protobuf for golang.
>
> https://github.com/golang/protobuf
>
>
> Using golang Protobuf, within *package **foo*, I created *message 
> TaskJobEntity* which is a combination of other messages:
>
>
> message TaskJobEntity {
> JobEntity job = 1; 
> TaskEntity task = 2; 
> map dependent_jobs = 3; 
>
> } 
>
>
> Which is used within *package foo* response as part a *map*:
>
>
> message ListTaskJobsResponse {
> *map**** task_jobs* = 1; 
> ServiceStatus status = 2; 
> }
>
> Now within another Protobuf *package bar*, I would like to define 
> response that includes *message TaskJobEntity* defined in *package **foo*, 
> however, as far as I can determine, a *proto3* package cannot reference 
> another proto3 package (is this determination correct?).
>
>
> My goal is to add *map task_jobs* to 
> *package bar* defined response.
>
>
> Here is how I approaching to get to this goal. I have found that map of 
> *interface{}* is not supported in Protobuf. So, is using 
> *google.protobuf.Any* the next best solution?
>
>
> message ImportStatsResponse {
> string task_id = 1; 
> // map task_jobs = 2; 
> // map task_jobs = 2; 
> map task_jobs = 2; 
> ServiceStatus status = 3; 
> }
>
>
> Recommendations?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Protobuf and Golang: How to generate a map string interface using proto3?

['Feng Xiao' via Protocol Buffers]

On Tue, Dec 19, 2017 at 10:01 AM,  wrote:

> Hi, I am new in using Protobuf for golang.
>
> https://github.com/golang/protobuf
>
>
> Using golang Protobuf, within *package **foo*, I created *message
> TaskJobEntity* which is a combination of other messages:
>
>
> message TaskJobEntity {
> JobEntity job = 1;
> TaskEntity task = 2;
> map dependent_jobs = 3;
>
> }
>
>
> Which is used within *package foo* response as part a *map*:
>
>
> message ListTaskJobsResponse {
> *map**** task_jobs* = 1;
> ServiceStatus status = 2;
> }
>
> Now within another Protobuf *package bar*, I would like to define
> response that includes *message TaskJobEntity* defined in *package **foo*,
> however, as far as I can determine, a *proto3* package cannot reference
> another proto3 package (is this determination correct?).
>
What makes you think that? You can certainly import and use other proto3
packages.


>
> My goal is to add *map task_jobs* to
> *package bar* defined response.
>
>
> Here is how I approaching to get to this goal. I have found that map of
> *interface{}* is not supported in Protobuf. So, is using
> *google.protobuf.Any* the next best solution?
>
>
> message ImportStatsResponse {
> string task_id = 1;
> // map task_jobs = 2;
> // map task_jobs = 2;
> map task_jobs = 2;
> ServiceStatus status = 3;
> }
>
>
> Recommendations?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Protobuf and Golang: How to generate a map string interface using proto3?

[jefft]

 

Hi, I am new in using Protobuf for golang.

https://github.com/golang/protobuf


Using golang Protobuf, within *package **foo*, I created *message 
TaskJobEntity* which is a combination of other messages:


message TaskJobEntity {
JobEntity job = 1; 
TaskEntity task = 2; 
map dependent_jobs = 3; 

} 


Which is used within *package foo* response as part a *map*:


message ListTaskJobsResponse {
*map**** task_jobs* = 1; 
ServiceStatus status = 2; 
}

Now within another Protobuf *package bar*, I would like to define response 
that includes *message TaskJobEntity* defined in *package **foo*, however, 
as far as I can determine, a *proto3* package cannot reference another 
proto3 package (is this determination correct?).


My goal is to add *map task_jobs* to 
*package bar* defined response.


Here is how I approaching to get to this goal. I have found that map of 
*interface{}* is not supported in Protobuf. So, is using 
*google.protobuf.Any* the next best solution?


message ImportStatsResponse {
string task_id = 1; 
// map task_jobs = 2; 
// map task_jobs = 2; 
map task_jobs = 2; 
ServiceStatus status = 3; 
}


Recommendations?


-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.