[protobuf] Some great work!
Brilliant. I'm glad to see a protobuf descriptor editor come out of Google. I wrote my own using the XText 1.0 SDK but it was quick and dirty, I like this one much better. There are a few corner cases missing from the syntax however. I know I had a lot of trouble dealing with them using XText because the protobuf grammar has some oddities in it, especially when it comes to enumerations and custom options. The first couple things I noticed when I pulled up the protos I use are: 1) Imports are required to exist in the same directory as the importing proto. Is this intentional? When I used importURI in XText it allowed the files to simply be present in the same project, which allowed for more cleanly managing what proto files are part of the project and which are simply imports. (change in XText 2.0?) 2) Enum Value options are not supported by the current grammar. i.e. ...where the country code type is defined earlier in the same file and evo.name is defined by an import. 3) Custom options that are enumerations are not supported by the current grammar: I need to pull down the project and see if these would be easy to add to the grammar, but I would be glad to contribute to the project as I've been meaning to release my own for some time now and this is a much better starting point. Once I get a better look at the issues and possibly some solutions I'll post them to the project's issue tracker. Thanks for all the hard work - I'm very appreciative and I'm certain the rest of the protobuf community will be as well. -Ben Wright On Tuesday, August 2, 2011 10:26:52 PM UTC-4, Alex Ruiz wrote: Greetings, I'm proud to announce that today we released a new Eclipse-based editor for protocol buffer descriptors: https://code.google.com/p/protobuf-dt/. Please find the release announcement at the Google Open Source Blog: http://google-opensource.blogspot.com/2011/08/introducing-protobuf-dt-eclipse-editor.html We hope you find this editor useful. Please give it a try and let us know what you think. Regards, -Alex On Tuesday, August 2, 2011 10:26:52 PM UTC-4, Alex Ruiz wrote: Greetings, I'm proud to announce that today we released a new Eclipse-based editor for protocol buffer descriptors: https://code.google.com/p/protobuf-dt/. Please find the release announcement at the Google Open Source Blog: http://google-opensource.blogspot.com/2011/08/introducing-protobuf-dt-eclipse-editor.html We hope you find this editor useful. Please give it a try and let us know what you think. Regards, -Alex -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/z_jZIgMzUnoJ. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: Re:Re: [protobuf] Re: Is any method available to convert a protobuf object to XML?
Have you tried http://code.google.com/p/protostuff/ ? -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/hTS8SDZLVvgJ. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: NoClassDefFoundError
Did you remember to compile descriptor.proto with protoc? -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: NoClassDefFoundError
The descriptor.proto is the proto that describes proto files. This supports that Java and C++ reflection language feature and is required to be part of the java library. descriptor.proto is located at protobuf-2.4.1/src/google/protobuf/ descriptor.proto (with the C++ code) Please see the file included in the 2.4.1 distribution at protobuf-2.4.1/java/README.txt for instructions on how to properly build / install the java library without maven. I've included the relevant section below: Installation - Without Maven If you would rather not install Maven to build the library, you may follow these instructions instead. Note that these instructions skip running unit tests. 1) Build the C++ code, or obtain a binary distribution of protoc. If you install a binary distribution, make sure that it is the same version as this package. If in doubt, run: $ protoc --version If you built the C++ code without installing, the compiler binary should be located in ../src. 2) Invoke protoc to build DescriptorProtos.java: $ protoc --java_out=src/main/java -I../src \ ../src/google/protobuf/descriptor.proto 3) Compile the code in src/main/java using whatever means you prefer. 4) Install the classes wherever you prefer. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Numeric range not supported?
You can use custom field options to support validation of this type. Take a look at extending com.google.FieldOptions You can create an option field like max_inclusive and then access it at run-time from the FieldDescriptor and use the information for validation. Unfortunately this is still just a suggestion - you will still have to validate with custom-written code. PS: I have done this before and it worked out pretty well because the validation code did not have to have special information about the data structure, just access to the FieldDescriptor at run time. On May 30, 6:54 am, Marco Tedone marco.ted...@gmail.com wrote: Hi all, I'm checking the protobuf language definition and I couldn't find anywhere support for numeric range. In XSD, for instance, one could have: simpleType name=ZeroToTen restriction base=int minInclusive value=0 / maxInclusive value=10 / /restriction /simpleType However I couldn't find equivalent translation in the proto language definition. I could find defaults and enums, but not number ranges. Regards, Marco -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Message.getField(FieldDescriptor) and enum values.
Assuming you know the Java Enum Type for which the EnumValueDescriptor
is describing a type of...
MyJavaEnum.valueOf((EnumValueDescriptor)value)
will return the appropriate java enum value.
On May 23, 1:42 pm, Jim Mayer j...@pentastich.org wrote:
In the Java protocol buffer binding, is there a way to get the Java
enum value using protocol buffer reflection? Specifically, I'd like
to be able to write something like the following:
Object getFieldValue(MessageOrBuilder source, FieldDescriptor field)
{
Object value = source.getField(field);
if (value instanceof EnumValueDescriptor) {
return the Java enum corresponding to the descriptor;
} else {
return value;
}
}
As far as I can tell, this isn't possible as the methods that return
enums from the descriptors are all static on the enum class. Since
they are static, there is no way (short of reflection games) to invoke
them unless one has the class in hand. I would enjoy being proved
wrong :-)
What we'd really like to see is an easy mechanism that would give us
the following:
Something explicitValue = message.getXXX();
Object reflectionValue =
message.getTheJavaValueFromAFieldDescriptor(the field descriptor for
XXX);
assert explictValue == reflectionValue;
Similarly, we'd like to be able do the same thing for 'setXXX' methods
for builders, however in this case it's easy to go from an enum value
to its descriptor so we can get by with the 'setField' method.
Thanks!
-- Jim
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Proto file generation from Descriptors in Java (DebugString)
previous thread:
http://groups.google.com/group/protobuf/browse_thread/thread/4bf8bca8c88e82ba/dbaa2803984f3934?lnk=gstq=debugString()#dbaa2803984f3934
On May 18, 6:05 pm, Ben Wright compuware...@gmail.com wrote:
There has been some back and forth previously about java language
support for generating a proto file from a Descriptor.
The suggested implementation was to either wrap or port the
DebugString capability from decriptor.cc
I recently ported the DebugString capability to java - it's a bit
rough as it's a by-hand port from the c code, but I also fixed some
bugs in the way the file was generated. For instance, extended types
were not output with correct parenthesis around them and options that
were messages did not have appropriate {} around them - these could
easily be due to differences in the C and Java code though. I'd be
glad to elaborate further for anyone interested, but for now I'm
simply providing the ported code as static functions in a java file.
Notably, if integrated with the java library these functions should
probably not be in a static file, they should be included with their
appropriate descriptor types.
If it is decided that this functionality should be part of the Java
library, I would be willing to do the leg work and get these functions
in better shape and update the appropriate files. I can pass them
along in an issue report for a committer to check in.
Notably, if you're looking for someone to work on the Java library /
outstanding issues at all, I'm looking for something to do in my
mythical free time. I could help with c too, but I'm much stronger in
Java.
PS: This is all based on release 2.4.1
=== DebugString.java ===
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import java.util.Stack;
import com.google.protobuf.Descriptors.Descriptor;
import com.google.protobuf.Descriptors.EnumDescriptor;
import com.google.protobuf.Descriptors.EnumValueDescriptor;
import com.google.protobuf.Descriptors.FieldDescriptor;
import com.google.protobuf.Descriptors.FileDescriptor;
import com.google.protobuf.Descriptors.MethodDescriptor;
import com.google.protobuf.Descriptors.ServiceDescriptor;
import com.google.protobuf.Message;
import com.google.protobuf.TextFormat;
/**
* This class provides .proto file generation from Java Proto
Descriptors.
* brDerived from descriptor.cc in Protobuf 2.4.1
* br
* brbOriginal Copyright Notice from descriptor.cc:/b
* br
* br Protocol Buffers - Google's data interchange format
* br Copyright 2008 Google Inc. All rights reserved.
* brhttp://code.google.com/p/protobuf/
* br
* br Redistribution and use in source and binary forms, with or
without
* br modification, are permitted provided that the following
conditions are
* br met:
* br
* br * Redistributions of source code must retain the above
copyright
* br notice, this list of conditions and the following disclaimer.
* br * Redistributions in binary form must reproduce the above
* br copyright notice, this list of conditions and the following
disclaimer
* br in the documentation and/or other materials provided with the
* br distribution.
* br * Neither the name of Google Inc. nor the names of its
* br contributors may be used to endorse or promote products
derived from
* br this software without specific prior written permission.
* br
* br THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS
* br AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
NOT
* br LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR
* br A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT
* br OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
* br SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT
* br LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE,
* br DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY
* br THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT
* br (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE
* br OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
* br
* br Author: ken...@google.com (Kenton Varda)
* br Based on original Protocol Buffers design by
* br Sanjay Ghemawat, Jeff Dean, and others.
*
* @author Benjamin Wright (compuware...@gmail.com)
*/
public class DebugString {
private static void SubstituteAndAppend(StringBuilder contents,
String replace, Object... objects ) {
for(int i = 0; i objects.length; i++) {
final String old = $+i;
replace = replace.replace(old,
String.valueOf(objects[i]));
}
contents.append(replace
[protobuf] Proto file generation from Descriptors in Java (DebugString)
There has been some back and forth previously about java language
support for generating a proto file from a Descriptor.
The suggested implementation was to either wrap or port the
DebugString capability from decriptor.cc
I recently ported the DebugString capability to java - it's a bit
rough as it's a by-hand port from the c code, but I also fixed some
bugs in the way the file was generated. For instance, extended types
were not output with correct parenthesis around them and options that
were messages did not have appropriate {} around them - these could
easily be due to differences in the C and Java code though. I'd be
glad to elaborate further for anyone interested, but for now I'm
simply providing the ported code as static functions in a java file.
Notably, if integrated with the java library these functions should
probably not be in a static file, they should be included with their
appropriate descriptor types.
If it is decided that this functionality should be part of the Java
library, I would be willing to do the leg work and get these functions
in better shape and update the appropriate files. I can pass them
along in an issue report for a committer to check in.
Notably, if you're looking for someone to work on the Java library /
outstanding issues at all, I'm looking for something to do in my
mythical free time. I could help with c too, but I'm much stronger in
Java.
PS: This is all based on release 2.4.1
=== DebugString.java ===
import java.io.IOException;
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import java.util.Stack;
import com.google.protobuf.Descriptors.Descriptor;
import com.google.protobuf.Descriptors.EnumDescriptor;
import com.google.protobuf.Descriptors.EnumValueDescriptor;
import com.google.protobuf.Descriptors.FieldDescriptor;
import com.google.protobuf.Descriptors.FileDescriptor;
import com.google.protobuf.Descriptors.MethodDescriptor;
import com.google.protobuf.Descriptors.ServiceDescriptor;
import com.google.protobuf.Message;
import com.google.protobuf.TextFormat;
/**
* This class provides .proto file generation from Java Proto
Descriptors.
* brDerived from descriptor.cc in Protobuf 2.4.1
* br
* brbOriginal Copyright Notice from descriptor.cc:/b
* br
* br Protocol Buffers - Google's data interchange format
* br Copyright 2008 Google Inc. All rights reserved.
* br http://code.google.com/p/protobuf/
* br
* br Redistribution and use in source and binary forms, with or
without
* br modification, are permitted provided that the following
conditions are
* br met:
* br
* br * Redistributions of source code must retain the above
copyright
* br notice, this list of conditions and the following disclaimer.
* br * Redistributions in binary form must reproduce the above
* br copyright notice, this list of conditions and the following
disclaimer
* br in the documentation and/or other materials provided with the
* br distribution.
* br * Neither the name of Google Inc. nor the names of its
* br contributors may be used to endorse or promote products
derived from
* br this software without specific prior written permission.
* br
* br THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS
* br AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
NOT
* br LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR
* br A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT
* br OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
* br SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT
* br LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE,
* br DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY
* br THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT
* br (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE
* br OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
* br
* br Author: ken...@google.com (Kenton Varda)
* br Based on original Protocol Buffers design by
* br Sanjay Ghemawat, Jeff Dean, and others.
*
* @author Benjamin Wright (compuware...@gmail.com)
*/
public class DebugString {
private static void SubstituteAndAppend(StringBuilder contents,
String replace, Object... objects ) {
for(int i = 0; i objects.length; i++) {
final String old = $+i;
replace = replace.replace(old,
String.valueOf(objects[i]));
}
contents.append(replace);
}
private static String PrintFieldValueToString(Message message,
FieldDescriptor fieldDescriptor, int i) {
return valueAsString(fieldDescriptor,
message.getField(fieldDescriptor));
}
private static String DefaultValueAsString(FieldDescriptor
fieldDescriptor, boolean
[protobuf] Re: Generated hashcode() returns different values across JVM instances?
Jay: Using the class name to generate the hashcode is logically incorrect because the class name can be derived by the options java_package_ name and java_outer_classname. Additionally (although less likely to matter), separate protocol buffer files can define an identical class names with different protocol buffers. Lastly, and most importantly... If the same Message is being used with generated code and with dynamic code, the hash code for the descriptor would still be identical if generated from the descriptor instance, whereas the dynamic usage does not have a classname from which to derive a hashcode. While in your case this should not matter, it does matter for other users of protobuf. The hashcode function would be better served by being implemented correctly from state data for the descriptor. Additionally, in generated code it seems that this hashcode could be pre-computed by the compiler and Descriptor.hashcode() could return a constant integer - which would be much more efficient than any other method. On May 11, 3:02 pm, Jay Booth jaybo...@gmail.com wrote: It can be legitimate, especially in the case of Object.hashCode(), but it's supposed to be in sync with equals() by contract. As it stands, two objects which are equal() will produce different hashes, or the same logical object will produce different hashes across JVMs. That breaks the contract.. if the equals() method simply did return (other == this), then it'd be fine, albeit a little useless. I created an issue and posted a 1-liner patch that would eliminate the problem by using getClass().getName().hashCode() to incorporate type information into the hashCode without depending on a Descriptor object's memory address. On May 11, 12:01 am, Dmitriy Ryaboy dvrya...@gmail.com wrote: Hi Jay, I encountered that before. Unfortunately this is a legitimate thing to do, as documented in Object.hashCode() I have a write-up of the problem and how we wound up solving it (not elegant.. suggestions welcome) here:http://squarecog.wordpress.com/2011/02/20/hadoop-requires-stable-hash... D On Mon, May 9, 2011 at 8:25 AM, Jay Booth jaybo...@gmail.com wrote: I'm testing an on-disk hashtable with Protobufs and noticed that with the java generated hashcode function, it seems to return a different hashcode across JVM invocations for the same logically equivalent object (tested with a single string protobuf, same string for both instances). Is this known behavior? Bit busy right now backporting this to work with String keys instead but I could provide a bit of command line code that demonstrates the issue when I get a chance. Glancing at the generated hashcode() function, it looks like the difference comes from etiher getDescriptorForType().hashCode() or getUnknownFields().hashCode(), both of which are incorporated. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Generated hashcode() returns different values across JVM instances?
Alternatively... instead of putting the onus on the compiler, the
hashcode could be computed by the JVM at initialization time for the
Descriptor instance, (which would also help performance of dynamically
parsed Descriptor instance hashcode calls).
i.e.
private final int computedHashcode;
public Descriptor() {
//initialization
computedHashcode = do_compute_hashCode();
}
public int hashCode() {
return computedHashcode;
}
punlic int do_compute_hashCode(){
return // compute hashcode
}
This is all talking towards optimum performance implementation... the
real problem is the need for a hashCode implementation for Descriptor
based on the actual Descriptor's content...
On May 11, 4:54 pm, Ben Wright compuware...@gmail.com wrote:
Jay:
Using the class name to generate the hashcode is logically incorrect
because the class name can be derived by the options java_package_
name and java_outer_classname.
Additionally (although less likely to matter), separate protocol
buffer files can define an identical class names with different
protocol buffers.
Lastly, and most importantly...
If the same Message is being used with generated code and with dynamic
code, the hash code for the descriptor would still be identical if
generated from the descriptor instance, whereas the dynamic usage does
not have a classname from which to derive a hashcode. While in your
case this should not matter, it does matter for other users of
protobuf. The hashcode function would be better served by being
implemented correctly from state data for the descriptor.
Additionally, in generated code it seems that this hashcode could be
pre-computed by the compiler and Descriptor.hashcode() could return a
constant integer - which would be much more efficient than any other
method.
On May 11, 3:02 pm, Jay Booth jaybo...@gmail.com wrote:
It can be legitimate, especially in the case of Object.hashCode(), but
it's supposed to be in sync with equals() by contract. As it stands,
two objects which are equal() will produce different hashes, or the
same logical object will produce different hashes across JVMs. That
breaks the contract.. if the equals() method simply did return (other
== this), then it'd be fine, albeit a little useless.
I created an issue and posted a 1-liner patch that would eliminate the
problem by using getClass().getName().hashCode() to incorporate type
information into the hashCode without depending on a Descriptor
object's memory address.
On May 11, 12:01 am, Dmitriy Ryaboy dvrya...@gmail.com wrote:
Hi Jay,
I encountered that before. Unfortunately this is a legitimate thing to
do, as documented in Object.hashCode()
I have a write-up of the problem and how we wound up solving it (not
elegant.. suggestions welcome)
here:http://squarecog.wordpress.com/2011/02/20/hadoop-requires-stable-hash...
D
On Mon, May 9, 2011 at 8:25 AM, Jay Booth jaybo...@gmail.com wrote:
I'm testing an on-disk hashtable with Protobufs and noticed that with
the java generated hashcode function, it seems to return a different
hashcode across JVM invocations for the same logically equivalent
object (tested with a single string protobuf, same string for both
instances).
Is this known behavior? Bit busy right now backporting this to work
with String keys instead but I could provide a bit of command line
code that demonstrates the issue when I get a chance.
Glancing at the generated hashcode() function, it looks like the
difference comes from etiher getDescriptorForType().hashCode() or
getUnknownFields().hashCode(), both of which are incorporated.
--
You received this message because you are subscribed to the Google
Groups Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Generated hashcode() returns different values across JVM instances?
I think we wrote those replies at the same time : )
You're right, at the cost of some additional hash collisions, the
simplest solution is to simply not include the type / descriptor in
the hash calculation at all.
The best / least-collision solutions with good performance would be
what I wrote in my previous post, but that requires that someone
(presumably a current committer) with sufficient knowledge of the
Descriptor types to have enough time to update the compiler and java
libraries accordingly.
Any input from a committer for this issue? Seems the simple solution
would take less than an hour to push into the stream and could make it
into the next release.
On May 11, 5:25 pm, Ben Wright compuware...@gmail.com wrote:
Alternatively... instead of putting the onus on the compiler, the
hashcode could be computed by the JVM at initialization time for the
Descriptor instance, (which would also help performance of dynamically
parsed Descriptor instance hashcode calls).
i.e.
private final int computedHashcode;
public Descriptor() {
//initialization
computedHashcode = do_compute_hashCode();
}
public int hashCode() {
return computedHashcode;
}
punlic int do_compute_hashCode(){
return // compute hashcode
}
This is all talking towards optimum performance implementation... the
real problem is the need for a hashCode implementation for Descriptor
based on the actual Descriptor's content...
On May 11, 4:54 pm, Ben Wright compuware...@gmail.com wrote:
Jay:
Using the class name to generate the hashcode is logically incorrect
because the class name can be derived by the options java_package_
name and java_outer_classname.
Additionally (although less likely to matter), separate protocol
buffer files can define an identical class names with different
protocol buffers.
Lastly, and most importantly...
If the same Message is being used with generated code and with dynamic
code, the hash code for the descriptor would still be identical if
generated from the descriptor instance, whereas the dynamic usage does
not have a classname from which to derive a hashcode. While in your
case this should not matter, it does matter for other users of
protobuf. The hashcode function would be better served by being
implemented correctly from state data for the descriptor.
Additionally, in generated code it seems that this hashcode could be
pre-computed by the compiler and Descriptor.hashcode() could return a
constant integer - which would be much more efficient than any other
method.
On May 11, 3:02 pm, Jay Booth jaybo...@gmail.com wrote:
It can be legitimate, especially in the case of Object.hashCode(), but
it's supposed to be in sync with equals() by contract. As it stands,
two objects which are equal() will produce different hashes, or the
same logical object will produce different hashes across JVMs. That
breaks the contract.. if the equals() method simply did return (other
== this), then it'd be fine, albeit a little useless.
I created an issue and posted a 1-liner patch that would eliminate the
problem by using getClass().getName().hashCode() to incorporate type
information into the hashCode without depending on a Descriptor
object's memory address.
On May 11, 12:01 am, Dmitriy Ryaboy dvrya...@gmail.com wrote:
Hi Jay,
I encountered that before. Unfortunately this is a legitimate thing to
do, as documented in Object.hashCode()
I have a write-up of the problem and how we wound up solving it (not
elegant.. suggestions welcome)
here:http://squarecog.wordpress.com/2011/02/20/hadoop-requires-stable-hash...
D
On Mon, May 9, 2011 at 8:25 AM, Jay Booth jaybo...@gmail.com wrote:
I'm testing an on-disk hashtable with Protobufs and noticed that with
the java generated hashcode function, it seems to return a different
hashcode across JVM invocations for the same logically equivalent
object (tested with a single string protobuf, same string for both
instances).
Is this known behavior? Bit busy right now backporting this to work
with String keys instead but I could provide a bit of command line
code that demonstrates the issue when I get a chance.
Glancing at the generated hashcode() function, it looks like the
difference comes from etiher getDescriptorForType().hashCode() or
getUnknownFields().hashCode(), both of which are incorporated.
--
You received this message because you are subscribed to the Google
Groups Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post
[protobuf] Eclipse Feature for authoring editing .proto files
Does anyone know of a (good) implementation for protocol buffer file editor in the Eclipse IDE? I've found a couple of scattered, incomplete, and abandoned protobuf- related eclipse plugins... but I'm just looking for a text editor implementation with syntax highlighting and content assist. I ask because I'm close to just creating one unless I'll be reinventing the wheel. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Generated Comments
I was wondering if there was any convenient way to add comments into
a .proto file that would be included in generated code for context
help.
If not, is there an existing plug-in project anyone knows of that
provides anything like that?
i.e.
message Foo {
option documentation = A Foo message, must contain Bar!;
required Bar bar = 1 [documentation=A Bar value, be sure to
consider the implications of Foo.];
}
Maybe this is something that should be considered / could be a code
generator plugin for protoc?
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: UnmodifiableLazyStringList is not Serializable
I agree with J.S. on this one - there are many situations in Java EE environments where Serializable is checked or java serialization used when it's not simple or feasible to leverage protobuf serialization. Most of these situations are invm / in memory transfers. Sometimes java serialization is used to clone objects or to safely pass them between ClassLoader scopes. I've run into this limitation with JBoss ESB and passing protocol buffer objects between services through the InVM message transport. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Protobuf in JAX-WS
Unfortunately JAX-WS (Java API for XML Web Services) only works directly with XML (anyone feel free to correct me if I'm misinformed in this regard as I've never fully explored using JAX-WS without XML) You have a couple of options though... If you want to stick with XML based web services you can go with using Base64 encoded protocol buffer message(s) in appropriate XML fields. Likewise you can return data this way. The drawbacks of this are that you're essentially throwing away a lot of the good that comes from web services being well defined in terms of argument and return data types. (Base64 is an encoding scheme for putting binary data in human readable data streams such as XML by only using displayable characters... encoding suffers a 4/3 size penalty as it takes four 6- bit chars to encode three 8-bit bytes) If you're more flexible you can implement a non-XML based web service using a RESTful model, or thin HTTP requests, to post and get protocol buffers directly as raw bytes. There are also some remoting services built on top of protocol buffers that act much like web services. I have not used any of them so I'll leave it to someone more versed in those to speak to them. If you want more info you can ask more questions or do a search on RESTful web services (and yes JAX-WS supports RESTful but still using XML...) Best of luck, Ben Wright On Mar 31, 10:38 pm, Canggih PW cangca...@gmail.com wrote: hi, Sorry, i'm new in Java. Currently, i make a web service using python (for server) and java (for client). Client-Server can updates data synchronously, i'm using long polling method. All i know about how to implement those thing is using JAX WS, to send request and read the callback response. But, JAX WS using XML. How can i using protobuf in JAX-WS, or there are any other library in java that can do it? Thanks in advance Canggih -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: How to use the FieldOptions in java
You need to use the field descriptor for the field you want to look
at.
You can get ahold of the field descriptor by using findFieldByName
or findFieldByNumber
FieldDescriptor myFieldDescriptor =
MyProtoFileClass.MyMessage.getDescriptor().findFieldByNumber(MyProtoFileClass.MyMessage.MYFIELD_FIELD_NUMBER);
(anybody know a better way to get field descriptors?)
Object myExtensionValue =
myFieldDescriptor.getOptions().getField(MyProtoFileClass.myfieldoption.getDescriptor());
On Mar 4, 8:49 am, Harpreet hpreet.si...@gmail.com wrote:
Hi,
I was scanning the Language Guide and saw that there are simple ways
to access the MessageOptions defined in the java code like:
String value =
MyProtoFile.MyMessage.getDescriptor().getOptions().getExtension(MyProtoFile.myOption);
However if i have a field option like (using the e.g. in Language
guide)
extend google.protobuf.FieldOptions {
optional float my_field_option = 50002;
}
optional int32 foo = 1 [(my_field_option) = 4.5];
How do I access the my_field_option value in Java. The
MyProtoFile.myFieldOption static member does exist, but I don't know
how to use it.
I have tried a lot of things, but was unable to figure out a way.
Thanks, Harpreet
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: issue with protocol buffers when using with java generics.
You will need to provide the type during construction of your
instance. You will also want to provide the Descriptor for the type
you want to deserialize in order to safely perform that step.
i.e.
public GPBFormat(ClassT clazz, Descriptor d) { //save the type
information to instance variables }
Notably, you should not be using T extends DynamicMessage as nothing
extends DynamicMessage... you want T extends Message or T extends
Message.
Alternately you can just use the DynamicMessage type as intended (an
unknown message type) and not use any parameterization, but this gets
trickier to use as a developer as you cannot access fields with direct
getters - you need to use the FieldDescriptors to access fields.
PS: I've written the class you're trying to write (a few times), and
I eventually went with not using parameterization at all but just
using Message and DynamicMessage directly and accessing fields using
FieldDescriptors.
On Feb 22, 2:00 pm, rameshr rudra.ram...@gmail.com wrote:
Hi all im very new to google protocol buffers and java generics.
In my application in one class im serializing and deserializing
objects using google protocl buffers and my class is parameterized by
actual google protocol buffer class.
following is the my code.
public class GPBFormatT extends DynamicMessage implements
IGPBFormatT {
@Override
public byte[] serialize(T t)
{
return t.toByteArray();
}
@Override
public T deSerialize( byte[] value)
{
//deSerialization implemenation.
}
in above code serialization is working fine.but the problem with is
deSerialization. in deSerialization method here i dont know about
actual type of T extends GeneratedMessage, without knowing concrete
class im unable to deSerialize the byte array into google protocol
buffer type.
one approach i know is we can send concrete type of message to
deSerialize method,but my app wont accept this style of code(becoz
when i write code like that,that code will be google protocl buffer
specific)
so how can i solve this without sending actual type to deSerialize
method.
plz replay.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: constants, enums, signed vs unsigned
Seems an odd use case to capture a constant in a proto file... but my suggestion would be to extend FileOptions or MessageOptions and provide options that hold your constant values. On Feb 14, 12:15 pm, maxw mwindi...@videotron.ca wrote: Hello, I didn't find crystal-clear confirmation in the documentation, but it looks like enum values are considered _signed_ 32-bit integers. When I try to assign 4294967295 to an enum value in a .proto file, protoc complains. Is there any way to have unsigned 32-bit integer constants? I did find on this forum a suggestion (Issue 60), which basically declares a Constants message, with fields that have default values - those default values can then be retrieved. This does work, and also has the benefit of allowing more types of constants (than just 32-bit integers). The dilemma that I'm facing is what should be the guideline to choose between enum and this default value trick? Would it be considered bad form to mix both styles? Thank you! -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Alternate names for enumeration values
I have just the solution for you...
I'll start by warning you that I use PB mainly in Java, so things may
look slightly different in C++ - but this method should still work.
You're going to want to define an extension to
google.protobuf.EnumValueOptions
in your .proto file you will need to add an import for
descriptor.proto
import descriptor.proto;
then you will need to extent EnumValueOptions
extend google.protobuf.EnumValueOptions {
optional string friendly_name = 5000;
}
you will now have defined an EnumValueOption for your friendly
name... you can use it by adding...
enum my_enum {
FOO = 1 [(my.package.name.name)=Foo];;
BAR = 2 [(my.package.name.name)=Bar];;
}
Note that if you have a package defined - you will need to use it when
referencing your extension.. If not, just use [(friendly_name)=]
The () are important as this tells PB that you are referencing an
Extension.
In Java you can access these by calling (probably similar in C++)
enumValueDescriptor.getOptions().getExtension(MyProtobufOuterClass.friendly_name);
You will now have successfully defined a fixed string for each enum
value you want one for - you can do the same to associate the ordinals
of an existing enumeration with one you're using in protobuf by
defining an ordinal extension of type uint32.
-Benjamin Wright
On Feb 3, 9:42 pm, MahlerFive jefflegw...@gmail.com wrote:
Is there a way to assign alternate names to enumeration values? I have
a piece of C++ code that processes protocol buffer messages which have
a lot of enums in them, and I need to print out the contents in a user-
friendly, readable way.
I know that I can get the enum value name by doing something like:
pb::constants::EnumName_descriptor()-FindValueByNumber()-name()
But if my enum value name is DEVICE_CATEGORY_TABLET, I would rather
output something like Tablet. I can make a bunch of big maps of enum
values to strings in my C++ code, but this means that any time I
change the protocol buffers I need to update the C++ code. If there is
no alternate name available, is there perhaps a better way to
approach this where I don't have to make updates in two places for
every change?
Thanks!
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Generate .proto file from FileDescriptor?
Anyone know if this can be accomplished without resorting to JNI? On Feb 3, 4:01 pm, Jason Hsueh jas...@google.com wrote: C++'s FileDescriptor::DebugString() produces text that is reparsable as a .proto file On Thu, Feb 3, 2011 at 12:52 PM, Ben Wright compuware...@gmail.com wrote: I've started a project generating new FileDescriptors at runtime in Java using FileDescriptorProto in order to dynamically extend a base type. I have a class that generates .proto files (StringBuilder) and one that generates FileDescriptorProto. What I was wondering was if there was a class (in java or c++ that can turn a FileDescriptor / FileDescriptorProto into a .proto text file. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
