Evan is correct. The best way to write code which deals with a generic
protobuf type is to have it take a default instance as a parameter. From
that you can do everything else.
This is actually better than passing around Class objects, because it allows
users to use DynamicMessages with your cod
On Dec 6, 2010, at 10:31 , Koert Kuipers wrote:
But that doesn't make a parseFrom() in message interface invalid,
does it?
Indeed some other information outside the raw bytes will be needed
to pick to right Message subclass. But that's fine.
Oh, sorry, I misunderstood your question, so my an
But that doesn't make a parseFrom() in message interface invalid, does it?
Indeed some other information outside the raw bytes will be needed to pick
to right Message subclass. But that's fine.
One could then:
1) pick the right subclass of Message based upon some information outside
the raw bytes
On Dec 6, 2010, at 9:05 , Koert Kuipers wrote:
i am still confused why protobuffers does not have a parseFrom()
method in the message Interface. that would have been a lot cleaner
i think. or am i missing something?
Because the serialized representation does not include anything to
describ
hey
thanks for replies. this works indeed. unfortunately i saw the reply below
to late, and ended up writing something very similar over weekend... (took
me a while to figure the klass.getMethod("getDefaultInstance").invoke(null)
trick out).
i ended up caching the default instances for multiple p
Here is the snippet ...
public class ProtocolBufferSerializationProvider {
private final Class type;
private final T instance;
//..
@SuppressWarnings("unchecked")
public T deserialize(byte[] data) throws
InvalidProtocolBufferException {
What u are doing will work. You extend message
An then u can call a get builder function. With
That you can merge from bytes. I don't have a computer
right now but if u post again if you don't find the
function and I'll post a snippet on Monday.
On Dec 3, 3:21 pm, Koert Kuipers wrote:
> Hey all,
