jute's Introduction

Jute

Jute is a implementation of Apache Zookeepers's jute IDL and generation code written in pure Go. This module includes a parser to real the jute DDL file into an AST and then a generator to generate serialization/deserialization code.

Jute started out as a serialization format for Hadoop and is no longer being used (Hadoop moved to Apache Avro as such only Zookeeper seems to be using it.

Note: There may be work in future versions of Zookeeper to use a different format as well (see: ZOOKEEPER-102).

Each jute module is mapped to a Go package with each class getting it's own go file.

Usage

$ go get github.com/go-zookeeper/jute/cmd/jutec
$ jutec input.jute

You can control the output folder structure with the go.moduleMap and go.prefix options.

go.prefix can control the import prefix for the generated packages. Packages generated will append this prefix to the package names, however the prefix is not used in the generated directories.

go.moduleMap uses regular expressions to rewrite module names to go packages names. The format for this option is <regexp match>:<regexp replacement>. If the replacement string is - then the module is skipped and no code is generated. All moduleMaps are processed in order. Unlike go.prefix any mapped modules will be represented in the generated directory structure for the packages.

Example

This command will ignore the org.apache.zookeeper.server.* and the org.apache.zookeeper.txn modules. All other modules matching org.apache.zookeeper will drop the org.apache.zookeeper prefix. All generated modules will have the prefix github.com/go-zookeeper/zk/internal appended to it (for imports) but it won't be incuded in the directories.

$ jutec \
    -go.moduleMap=org.apache.zookeeper.server:- \
    -go.moduleMap=org.apache.zookeeper.txn:- \
    -go.moduleMap=org.apache.zookeeper: \
    -go.prefix=github.com/go-zookeeper/zk/internal \
    testdata/zookeeper.jute

Caveats

This is pretty experimental code. There are a lot of error checking missing, imports are not implemented and there are probably some pretty bad bugs. You have been warned!

TODO

Parser

Check for duplicate field names
Validate external module class fields
Block reserved keywords

Generator

Support imported jute files

jute's People

Contributors

Stargazers

Watchers

jute's Issues

Getters and Setters

Getters and Setters are not idiomatic.

Should they be removed from the code generation?

build/test: go-fuzz or similar to for more confidence

Testing the core lib/go/jute with go-fuzz system can give another layer of confidence.

build/test: have tests check or test against reference implementations

Sanity tests against checked-in, serialized payloads generated by the reference implementations (C or Java) of Jute.

It would be nice to see if we are in line with known good reference implementations.

string type converts to a pointer

Why is the string type converted to a string pointer?

Example:

https://github.com/go-zookeeper/jute/blob/master/testdata/fixtures/zookeeper/data/id.go#L13

Reference:

https://github.com/go-zookeeper/jute/blob/master/generate/gogen/types.go#L135

references to other structs

I think that to be consistent with C++ we should not use references to other jute defined class/struct.

Example C++:

        class ACL : public ::hadoop::Record {
          private:
          int32_t perms;
          org::apache::zookeeper::data::Id id;

Example Go:

type ACL struct {
	Perms int32 // perms
	Id    *Id   // id
}

"generated from" comment

Use relative paths or avoid adding the comment at all.

Code reference:

https://github.com/go-zookeeper/jute/blob/master/generate/gogen/generator.go#L217

Comment reference:

go-zookeeper/zk#31 (comment)

Recommend Projects

go-zookeeper / jute Goto Github PK