Hello.
I have a PB builder I build and write to a stream from a servlet-based
webapp thousands of times/second.
Something like the following
Protos.Response.Builder respBuilder =
Protos.Response.newBuilder().setFoo(12).setBar(345); // etc. . .
Protos.Response response =
Hello.
From what I gather catching up on list messages, 2.4 is final, but not
officially released, perhaps because some documentation is in the works.
I ask because I would like to incorporate 2.4 in my product's upcoming build
cycle, but only if there is reasonable certainty that the bits
I think this is a reasonable use of the list, particularly since you're
moderating such posts.
david dabbs
From: protobuf@googlegroups.com [mailto:proto...@googlegroups.com] On Behalf
Of Kenton Varda
Sent: Monday, December 13, 2010 1:07 AM
To: Protocol Buffers
Subject: [protobuf] Allow
fixed internally but the changes have not
been released yet.
(Although, the code you referenced is the code to generate the
clearFoo() method, which still must set things to the default)
On Wed, Sep 8, 2010 at 1:05 PM, David Dabbs wrote:
IIRC Java initializes these primitive types as
private
IIRC Java initializes these primitive types as
private boolean foo_boolean;// false
private int foo_int;// 0
private longfoo_long; // 0L
private float foo_float; // 0.0f
private double foo_double; // 0.0d
But java_primitive_field.cc
of strings to en/decode was small.
Did the same hold true when using a ThreadLocal?
David
-Original Message-
From: Evan Jones [mailto:ev...@mit.edu]
Sent: Monday, May 31, 2010 4:32 PM
To: David Dabbs
Cc: Protocol Buffers
Subject: Re: [protobuf] Java UTF-8 encoding/decoding: possible
The approach I found worked the best:
1. Copy the string into a pre-allocated and re-used char[] array. This
is needed since the JDK does not permit access to the String's
char[] ,to enforce immutability. This is a performance loss VS the
JDK, which can access the char[] directly
Obviously, if you want you can use it to mutate the object, but if you like
you can mutate even
perfectly final and immutable objects in Java (using some trickery).
I'm pretty sure that's not true. Effective Java, for example, suggests
using immutable classes as a
security measure, which
