Thrift: using an external java class in list definition

Question

I'm newbie to Thrift and would greatly appreciate some help in writing the Thrift generator file. I want to use a Java server with many clients in various languages. I'm using Thrift to autogenerate these files.

Here's my Thrift file:

namespace php example
namespace py example
namespace csharp example
namespace cpp example
namespace perl example
namespace d example
namespace java javaobjectmethods

struct ExternalLibraryItem {
    1: required string name
}

service ExampleService {
    list<ExternalLibraryItem> javaObjectMethod(1:i32 count)
}

I have a separate set of Java files that is in the package javaObject and javaObjectMethod is one of the methods in the package. However, this method returns an object that is instantiated by an external library. How do I write this in the Thrift file without the:

struct ExternalLibraryItem {
    1: required string name
}

It currently won't let my generate the server files without this line.

Here's my Java file:

package javaobjectmethods;

import externalLibrary.ExternalLibaryItem;
import externalLibrary.ExternalLibraryClass;

public class javaObject {
    private String file;

    public javaObject(String file) {
        this.file = file;
    }

    public List<ExternalLibraryItem> javaObjectMethod(int count) {
        // this method returns List<ExternalLibraryItem>
        return ExternalLibraryClass.doThis(count, this.file);
    }
}

Answer 1

Short answer: You can't.

All Thrift structs are expected to be generated code. For some languages, partial classes are created which (e.g. C#) can help in such situations, but not for all. Also, in some cases (C++) the base class can be customized to some extent. For Java, the

struct Foo {
  1: i32 bar
}

results in a class starting with

public class foo implements org.apache.thrift.TBase<foo, foo._Fields>, 
                            java.io.Serializable, 
                            Cloneable, 
                            Comparable<foo>

which is all needed and expected by the surrounding code and structures.

One possible solution for your particular case is to convert the internal classes into Thrift classes and vice versa.

_{Of course, if you have a cool idea how to do this better - we are open for quality patches.}