java class name different from proto file name

[Tai]

I got a strange behaviour when compiling a protofile (e.g.
MyClass.proto). The generated java class is then called MyClassProto.
All other proto files works fine. As a workaround I have added the
following line to the proto file:

option java_outer_classname = "MyClass";

Any idea what I am doing wrong?

Thanks Tai

[Stefan]

Are you using Windows by any chance?

[Tai]

Yes, I am using Windows XP and Eclipse 3.5

[Tai]

What it is also funny is that my file ADMObjectHandleMessage.proto
looks like this:

package com.qnamic.base.agent;
option java_outer_classname = "ADMObjectHandleMessage";
message ADMObjectHandle {
optional string host = 1;
optional string agent = 2;
optional string path = 3;
optional int64 admTopCreationTime = 4;
}

And the in descriptor has a whitespace in my ADMObjectHandleMessage
class:

private static com.google.protobuf.Descriptors.FileDescriptor
descriptor;
static {
java.lang.String descriptorData =
"\n\035ADMObjectHandleMessage.proto \022\025com.qna" +
"mic.base.agent\"X\n\017ADMObjectHandle\022\014\n\004hos" +
"t\030\001 \001(\t\022\r\n\005agent\030\002 \001(\t\022\014\n
\004path\030\003 \001(\t\022\032\n\022" +
"admTopCreationTime\030\004 \001(\003B\030B\026ADMObjectHan" +
"dleMessage";

So what you see here is "ADMObjectHandleMessage.proto " and not
"ADMObjectHandleMessage.proto". My other classes looks fine. The
problem is that I have AbstractADMAdapterMessage.proto using this:
package com.qnamic.planopt.base.query.adapter;
import "ADMObjectHandleMessage.proto";

message AbstractADMAdapter {
required com.qnamic.base.agent.ADMObjectHandle objectHandle = 1;
required bool adaptAll = 2;
required bool fillObjectHandle = 3;
}

The problem is that when the descriptor of the second class gets
initialized I get an Exception in Descriptors.FileDescriptor.buildFrom
() saying:
Dependencies passed to FileDescriptor.buildFrom() don't match those
listed in the FileDescriptorProto.

because the name does not match with each other:
"ADMObjectHandleMessage.proto ".equals("ADMObjectHandleMessage.proto")

What am I doing wrong?

Tai

On 4 Aug., 19:49, Stefan <sneg...@gmail.com> wrote:

[Kenton Varda]

It looks like your problem is that your file name actually has a space tacked on to the end of it.  That is, the name is "MyClass.proto " <- note the last space.  You should get rid of that space.

[Tai]

Thanks. Your were pointing into the right direction. It wasn't the
filename but the compile argument when using ant:

<project name="Create PB classes" default="generate"
basedir="../../../..">
<target name="generate">
<exec executable="D:/development/workspace/Platform/dev/jars/
protoc">
<arg value="-I=Platform/dev/config/protocolbuffers" />
<arg value="--java_out=Platform/src" />
<arg value="Platform/dev/config/protocolbuffers/
ADMObjectHandleMessage.proto" />
<arg value="Platform/dev/config/protocolbuffers/
ADMTimeMessage.proto" />
</exec>
</target>
</project>

The argument was:
value="Platform/dev/config/protocolbuffers/
ADMObjectHandleMessage.proto "
and not:
value="Platform/dev/config/protocolbuffers/
ADMObjectHandleMessage.proto"

Tai

On 4 Aug., 22:12, Kenton Varda <ken...@google.com> wrote:
> It looks like your problem is that your file name actually has a space
> tacked on to the end of it.  That is, the name is "MyClass.proto " <- note
> the last space.  You should get rid of that space.
>

[Kenton Varda]

In that case I'm surprised it compiled -- I would have expected protoc to report "file not found".  Weird.

[Tai]

This could be a windows problem where white spaces are accepted when
doing a file lookup. I further assume when protoc takes the argument
it uses the filename including the white space to generate the class
name. Maybe that was the reason why the class was called
"MyClassProto" and not "MyClass".

Tai

On 4 Aug., 23:19, Kenton Varda <ken...@google.com> wrote:
> In that case I'm surprised it compiled -- I would have expected protoc to
> report "file not found".  Weird.
>

[Kenton Varda]

Yes, that's correct.  If the Win32 API strips trailing whitespace from file names when opening them, that would explain why there was no error -- but that's very strange behavior IMO.

[Tai]

That's not strange. That's a Windows feature :-)

On 5 Aug., 01:50, Kenton Varda <ken...@google.com> wrote:
> Yes, that's correct.  If the Win32 API strips trailing whitespace from file
> names when opening them, that would explain why there was no error -- but
> that's very strange behavior IMO.
>