[protobuf] Re: Issue 59 in protobuf: Add another option to support java_implement_interface

[protobuf]

Comment #14 on issue 59 by t.broyer: Add another option to support  
java_implement_interface

http://code.google.com/p/protobuf/issues/detail?id=59

@kenton: neat idea! and it's not necessarily too late to add this as an  
alternate API
to the existing writeTo/parseFrom/mergeFrom methods, to show the path to  
plugin

developers.

@aantono: a priori, there would be a need for 2 base interfaces:
 - for text formats, using Appendable and Readable (and String), and/or  
Writer and

Reader
 - for binary formats, using OutputStream/InputStream (and ByteString,  
and/or

byte[]).
(BTW, I already knew protobuf-java-format, but it's based on the reflection  
API and

is not "GWT-translatable" to JavaScript)

--
You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to proto...@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 59 in protobuf: Add another option to support java_implement_interface

[protobuf]

Comment #13 on issue 59 by aantono: Add another option to support  
java_implement_interface

http://code.google.com/p/protobuf/issues/detail?id=59

just an FYI, as its mentioned in issue 82, there is already a set  
of "formatters" for JSON, XML, etc, as part of the

http://code.google.com/p/protobuf-java-format/ project.
I've been toying around with an idea of making a common interface that they  
would all implement, so maybe then
we could enhance the code generation part to accept any formatter/codec  
class which will be coded to a well-

known interface.

--
You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to proto...@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 59 in protobuf: Add another option to support java_implement_interface

[protobuf]

Comment #12 on issue 59 by ken...@google.com: Add another option to support  
java_implement_interface

http://code.google.com/p/protobuf/issues/detail?id=59

For the alternate codec case, I think a better approach would be to  
generate a

separate class to perform the encoding/decoding.  E.g.:

  interface JsonProtobufCodec {
String encode(T message);
T decode(String json);
  }

Then in generated code:

  class FooMessage {
...
// inserted by your plugin:
public static final JsonProtobufCodec JSON_CODEC =
  new JsonProtobufCodec {
...
  };
  }

This requires that you pass the JSON codec object around together with your  
protobuf
object, but this is not a terrible requirement in practice.  I actually  
wish that we
had designed the native format this way, rather than building it into the  
class
itself, as it's more modular.  Also, with this design, you could provide a  
dynamic
implementation of JsonProtobufCodec which would work with DynamicMessage.   
You could
also allow your code generator to work stand-alone, generating a separate  
file,
allowing people to generate fast JSON codecs for protos whose code  
generation they

don't control (e.g. descriptor.proto).

--
You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to proto...@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 59 in protobuf: Add another option to support java_implement_interface

[protobuf]

Comment #11 on issue 59 by t.broyer: Add another option to support  
java_implement_interface

http://code.google.com/p/protobuf/issues/detail?id=59

Attached is a patch that adds insertion points (Java only) for code  
generator
plugins. It uses a redundant but harmless "implements Message(Lite)" so  
that a plugin

always inserts ", MyInterface" without risking conflict with another plugin
(otherwise a plugin would have to know whether another has already inserted  
the

"implements" keyword).

My use case for resurrecting this issue is JSON or GWT-RPC  
ser/de-serialization (see
issue 82 too) without using the reflection interface (for use in a "lite"  
environment
or for "code speed") with polymorphism support. The only workaround is to  
patch your
libprotobuf.jar by "augmenting" the MessageLite interface (but then you'd  
rather

patch your protoc than write a code generator plugin too)

Note that I do not have a C++ build environment, so I didn't even compile  
the patched

code.

Attachments:
java_implements_insertion_point.patch  6.0 KB

--
You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to proto...@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: [protobuf] Re: Add another option to support java_implement_interface

[Kenton Varda]

On Tue, Nov 24, 2009 at 6:45 PM, Alex Antonov  wrote:

> > Rewriting the protocol compiler to use some sort of template system is
> not
> > something we really have resources for.  That said, the plugins thing I'm
> > working on may be useful to similar ends.
>
> Oh, the plugins stuff sounds interesting.  Is there anything on the
> discussion board about it, or still in the works?
>

I send an e-mail awhile back discussing my design.  Search for "plugin" or
"plugins".

--

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@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: Add another option to support java_implement_interface

[Alex Antonov]

> Rewriting the protocol compiler to use some sort of template system is not
> something we really have resources for.  That said, the plugins thing I'm
> working on may be useful to similar ends.

Oh, the plugins stuff sounds interesting.  Is there anything on the
discussion board about it, or still in the works?

--

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@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: [protobuf] Re: Add another option to support java_implement_interface

[Kenton Varda]

On Mon, Nov 23, 2009 at 7:50 PM, Alex Antonov  wrote:

> Kenton,
>
> Those are all good points, I agree with you that this kinda coupling
> could be dangerous and cause trouble if mismanaged.
> I'm trying to think of a way to keep this protoc safe but at the same
> time provide the kind of functionality the interface declaration would
> bring.
> Problem is that having the interface support requires the code to be
> actually compiled with the interface declaration, so nothing along the
> lines of doing something "magical" with dynamic proxies or anything
> like that seem like it would work (without using the reflection that
> is).  Anything proposed by Chris with separating the declarations via
> "java_ext" that might work?
>

Not sure what you mean.


> How about some sort of a templating support maybe (I remember we were
> discussing that at some point for the "setOrClear" support)?
>

Rewriting the protocol compiler to use some sort of template system is not
something we really have resources for.  That said, the plugins thing I'm
working on may be useful to similar ends.

--

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@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: Add another option to support java_implement_interface

[Alex Antonov]

Kenton,

Those are all good points, I agree with you that this kinda coupling
could be dangerous and cause trouble if mismanaged.
I'm trying to think of a way to keep this protoc safe but at the same
time provide the kind of functionality the interface declaration would
bring.
Problem is that having the interface support requires the code to be
actually compiled with the interface declaration, so nothing along the
lines of doing something "magical" with dynamic proxies or anything
like that seem like it would work (without using the reflection that
is).  Anything proposed by Chris with separating the declarations via
"java_ext" that might work?
How about some sort of a templating support maybe (I remember we were
discussing that at some point for the "setOrClear" support)?

--

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@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: Add another option to support java_implement_interface

[Alex Antonov]

For some reason this thread got forked: here is the second copy:
http://groups.google.com/group/protobuf/browse_thread/thread/c4efd9f017d0b014?hl=en&tvc=2

--

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@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: [protobuf] Re: Add another option to support java_implement_interface

[Kenton Varda]

Google's build system requires all dependencies to be explicitly declared
and enforces this.  This is needed in order for the system to scale to very
large code trees:  when we want to compile a particular program or test, we
want to compile only the things it depends on, not the whole tree.  The
build system further assumes that protoc-generated Java code depends only on
libprotobuf.jar, so that's the only thing it puts in the classpath when
compiling that code.  To change that, we'd have to add new features to the
build definition language to allow you to declare a Java library as a
dependency of a Proto library.  This is something I have tried to avoid
because an earlier version of protocol buffers allowed it (even though it
was never actually needed), and the result was that people would declare
dependencies that were not actually necessary, thus forcing everyone who
used their proto to depend on code they didn't need.

But this is just one example of the kind of quirks I'm talking about.
 Another one:  Imagine someone writes some code that can take .proto files
and compile them at runtime by invoking protoc and the java compiler in the
background, then tries to load the class files.  Currently, you could
theoretically do this.  With your feature, though, you can't anymore -- this
code would have to carefully go through and make sure to delete all
instances of the java_implement_interface option to make it work.

These are minor issues in isolation, but I worry that they are just a couple
examples of a large class of problems that would be caused by Java generated
code depending on arbitrary app code.

On Mon, Nov 23, 2009 at 6:28 PM, aantono  wrote:

> Kenton,
>
> You certainly can do that as well.  However, as you pointed out,
> that's a lot of extra code that one would have to hand-write and
> maintain.  This is why I thought it might be a good idea to solicit
> more opinions from the community to help get a better sense of what's
> the lesser of two evils.  I see your point of introducing the implicit
> dependency between protoc and application code, but it is implicit,
> and won't prevent one from generating the proto java objects, just
> won't compile afterwards if the declared interface is not present.
> But the same holds true for having the wrappers, if they are not
> present in the classpath at compile time, it won't work.  This
> dependency is isolated to a particular VM, but having an interface(s)
> allows for easier use of objects representing "concepts" without
> having to resort to reflection.  It seems to me that at the end of the
> day its all about the business needs and convenience, so the less code
> one has to write and maintain, the better.
>
> Also, can you elaborate (if possible) on why would this not work with
> Google's internal build system
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@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 proto...@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: Add another option to support java_implement_interface

[aantono]

Kenton,

You certainly can do that as well.  However, as you pointed out,
that's a lot of extra code that one would have to hand-write and
maintain.  This is why I thought it might be a good idea to solicit
more opinions from the community to help get a better sense of what's
the lesser of two evils.  I see your point of introducing the implicit
dependency between protoc and application code, but it is implicit,
and won't prevent one from generating the proto java objects, just
won't compile afterwards if the declared interface is not present.
But the same holds true for having the wrappers, if they are not
present in the classpath at compile time, it won't work.  This
dependency is isolated to a particular VM, but having an interface(s)
allows for easier use of objects representing "concepts" without
having to resort to reflection.  It seems to me that at the end of the
day its all about the business needs and convenience, so the less code
one has to write and maintain, the better.

Also, can you elaborate (if possible) on why would this not work with
Google's internal build system

--

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@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: [protobuf] Add another option to support java_implement_interface

[Kenton Varda]

The main problem with this is logistical:  By declaring that a protobuf
class should implement a Java interface, you are making protoc-generated
code depend on hand-written, app-specific code.  This means that the build
system must support declaring such dependencies, and that the .proto files
alone cannot be used if you don't have those additional files available.  It
sounds minor, but it leads to a lot of quirky problems.  The feature you're
suggesting would actually be impossible to use with Google's internal build
system, for instance.

Could you instead write wrapper classes which implement the interface in
terms of a particular message type?  For example, if all your message types
share a field "optional int32 id", and you have various code which wants to
operate on arbitrary messages as long as they have an id field.  You could
write:

  interface MessageWithId {
Message getMessage();
int getId();
  }

Then for any particular type, you could easily write an implementation of
this interface:

  class FooMessageWithIdAdaptor implements MessageWithId {
public FooMessageWithIdAdaptor(Foo foo) {
  this.foo = foo;
}

public Foo getMessage() { return foo; }
public int getId() { return foo.getId(); }

private final Foo foo;
  }

I understand that this is ugly, but allowing generated code to have
arbitrary dependencies is also pretty ugly for other reasons, so we have to
choose the lesser of two evils here.

On Mon, Nov 23, 2009 at 5:09 PM, aantono  wrote:

> Wanted to hear the community thoughts on adding another option to
> support java_implement_interface.
>
> I think it would be very beneficial to be able to have the protoc
> generate code
> that would be implementing some signature interfaces in the Java
> world.
>
> Unlike Python or Ruby, where if the method exists on an object, you
> can
> call it, in Java the methods must be declared on the classes, so it
> makes
> it difficult to write methods that could take multiple types of
> objects
> which are of Protocol Buffers type without being able to mark them
> with an
> Interface.
>
> I've opened an Issue 59 regarding this change and want to gauge the
> community thoughts on the usefulness of this option.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@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 proto...@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] Add another option to support java_implement_interface

[aantono]

Wanted to hear the community thoughts on adding another option to
support java_implement_interface.

I think it would be very beneficial to be able to have the protoc
generate code
that would be implementing some signature interfaces in the Java
world.

Unlike Python or Ruby, where if the method exists on an object, you
can
call it, in Java the methods must be declared on the classes, so it
makes
it difficult to write methods that could take multiple types of
objects
which are of Protocol Buffers type without being able to mark them
with an
Interface.

I've opened an Issue 59 regarding this change and want to gauge the
community thoughts on the usefulness of this option.

--

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@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: Add another option to support java_implement_interface

[Kenton Varda]

Hmm, that's a good idea.  They'd still have to be compiled into protoc, but
at least they wouldn't have to be compiled into client code.  The only
problem is that it adds complication, I suppose.
My second point is still an issue.

On Tue, Dec 2, 2008 at 8:23 AM, Chris <[EMAIL PROTECTED]> wrote:

> Kenton Varda wrote:
>
>> On Mon, Dec 1, 2008 at 6:46 PM, aantono <[EMAIL PROTECTED] > [EMAIL PROTECTED]>> wrote:
>>
>>message Person
>> java_implement_interface = com.domain.Name ;
>> required string name;
>> required int32 age;
>>}
>>
>>
>> More precisely:
>>
>> message Person {
>>  option java_implement_interface = "com.domain.Name <
>> http://com.domain.Name>";
>>  required string name = 1;
>>  required int32 age = 2;
>> }
>>
> Why not use the new mechanism, putting the java extensions into
> "java_ext.proto":
>
> import "java_ext";
>
> message Person {
>  option (java_ext.implement_interface) = "com.domain.Name <
> http://com.domain.Name>";
>  required string name = 1;
>  required int32 age = 2;
> }
>
>
>> And the effect of this is simply that when protoc generates the Person
>> class, it declares it as implementing com.domain.Name <
>> http://com.domain.Name>.
>>
>> This is a very simple change, so I may be convinced to accept it.  My main
>> concerns are:
>>
>> * Adding another option imposes non-zero overhead even on people who don't
>> use the option, since it increases the code generated for descriptor.proto.
>>  The size of descriptor.proto's generated code is already somewhat of a
>> problem.
>>
> The java_ext.proto code would not be part of descriptor.proto code.
>  Non-java targets could eliminate it.
>
>> * I'm somewhat uneasy with the idea of generated protobuf code depending
>> on non-generated code (other than standard libraries and libprotobuf).  This
>> goes against the model.  It would not work in our internal build system,
>> which assumes that protobuf code never has such dependencies.  I am worried
>> that making the model more complicated in this way will lead to other
>> problems down the road; e.g. if protocol buffers are integrated better into
>> other build systems, they may also dislike this.
>>
>> I can see where this feature would be useful but I'm not sure if it
>> outweighs these issues.
>>
>> What do other people think?
>>
> I think that having target specific "java_ext.proto", "python_ext.proto",
> and "cpp_ext.proto" that define hints to protoc's code generation would be a
> good idea.  The existing java* options and the "ctype=CORD" options are
> legacy examples that would be in "java_ext.proto" and "cpp_ext.proto" if
> redesigned today.  This way "descriptor.proto" is stable against adding
> target specific extensions.  The code bloat only occurs on the target
> platform, though there is data bloat in the reflection storage on all
> platforms.
>
> Is there any technical reason it could not go into a separate
> "java_ext.proto" 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: Add another option to support java_implement_interface

[Chris]

Kenton Varda wrote:
> On Mon, Dec 1, 2008 at 6:46 PM, aantono <[EMAIL PROTECTED] 
> > wrote:
>
> message Person
>  java_implement_interface = com.domain.Name ;
>  required string name;
>  required int32 age;
> }
>
>
> More precisely:
>
> message Person {
>   option java_implement_interface = "com.domain.Name 
> ";
>   required string name = 1;
>   required int32 age = 2;
> }
Why not use the new mechanism, putting the java extensions into 
"java_ext.proto":

import "java_ext";

message Person {
  option (java_ext.implement_interface) = "com.domain.Name 
";
  required string name = 1;
  required int32 age = 2;
}

>
> And the effect of this is simply that when protoc generates the Person 
> class, it declares it as implementing com.domain.Name 
> .
>
> This is a very simple change, so I may be convinced to accept it.  My 
> main concerns are:
>
> * Adding another option imposes non-zero overhead even on people who 
> don't use the option, since it increases the code generated for 
> descriptor.proto.  The size of descriptor.proto's generated code is 
> already somewhat of a problem.
The java_ext.proto code would not be part of descriptor.proto code.  
Non-java targets could eliminate it.
> * I'm somewhat uneasy with the idea of generated protobuf code 
> depending on non-generated code (other than standard libraries and 
> libprotobuf).  This goes against the model.  It would not work in our 
> internal build system, which assumes that protobuf code never has such 
> dependencies.  I am worried that making the model more complicated in 
> this way will lead to other problems down the road; e.g. if protocol 
> buffers are integrated better into other build systems, they may also 
> dislike this.
>
> I can see where this feature would be useful but I'm not sure if it 
> outweighs these issues.
>
> What do other people think?
I think that having target specific "java_ext.proto", 
"python_ext.proto", and "cpp_ext.proto" that define hints to protoc's 
code generation would be a good idea.  The existing java* options and 
the "ctype=CORD" options are legacy examples that would be in 
"java_ext.proto" and "cpp_ext.proto" if redesigned today.  This way 
"descriptor.proto" is stable against adding target specific extensions.  
The code bloat only occurs on the target platform, though there is data 
bloat in the reflection storage on all platforms.

Is there any technical reason it could not go into a separate 
"java_ext.proto" 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: Add another option to support java_implement_interface

[Kenton Varda]

On Mon, Dec 1, 2008 at 6:46 PM, aantono <[EMAIL PROTECTED]> wrote:

> message Person
>  java_implement_interface = com.domain.Name;
>  required string name;
>  required int32 age;
> }
>

More precisely:

message Person {
  option java_implement_interface = "com.domain.Name";
  required string name = 1;
  required int32 age = 2;
}

And the effect of this is simply that when protoc generates the Person
class, it declares it as implementing com.domain.Name.

This is a very simple change, so I may be convinced to accept it.  My main
concerns are:

* Adding another option imposes non-zero overhead even on people who don't
use the option, since it increases the code generated for descriptor.proto.
 The size of descriptor.proto's generated code is already somewhat of a
problem.

* I'm somewhat uneasy with the idea of generated protobuf code depending on
non-generated code (other than standard libraries and libprotobuf).  This
goes against the model.  It would not work in our internal build system,
which assumes that protobuf code never has such dependencies.  I am worried
that making the model more complicated in this way will lead to other
problems down the road; e.g. if protocol buffers are integrated better into
other build systems, they may also dislike this.

I can see where this feature would be useful but I'm not sure if it
outweighs these issues.

What do other people think?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Add another option to support java_implement_interface

[aantono]

I would like to propose an enhancement to the java options for protoc.
This enhancement would allow one to specify the java interface which
the generated proto object will implement.

It would be very beneficial to be able to have the protoc generate
code that would be implementing some signature interfaces in the Java
world.

Unlike Python or Ruby, where if the method exists on an object, you
can call it, in Java the methods must be declared on the classes, so
it makes it difficult to write methods that could take multiple types
of objects which are of Protocol Buffers type without being able to
mark them with an Interface. Just knowing that the object is of type
"Message" is not sufficient.

Imagine you have an interface Name defining a method getName().
Then I can have a bunch of protos defining various kinds of "names",
like Person,
City, Country, etc.  All of those objects have a "name" field, and
thus the getName()
method.  By marking them all with a 'Name' interface, I can then have
my business
logic code accept objects of 'Name' type as method arguments and be
guaranteed that
there is a "getName()" method on them.

The problem with doing it the "reflection" route is that it does not
guarantee me a
compile-time checking and is not as clean and java-esque.

The proposed syntax would be:
message Person
  java_implement_interface = com.domain.Name;
  required string name;
  required int32 age;
}

Please post your thoughts, comments & objections... :)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---