I second Clément's request: support for unboxed primitive types would be awesome!
The autoboxing question has been asked before on the forum, this post has a few workaround solutions (I haven't tried either of them yet): http://apache-avro.679487.n3.nabble.com/Generate-java-code-with-getters-returning-primitives-instead-of-wrapper-classes-td4032580.html Yomi -----Original Message----- From: Clément MATHIEU [mailto:clem...@unportant.info] Sent: 10 February 2016 23:40 To: user@avro.apache.org Subject: Java compiler: unboxed types & nullity Hi, Java code produced for getters & setters by the compiler always maps Avro primitive types to Java boxed types. The only exception is the setter of the builder. Using unboxed types when possible would both avoid boxing costs, if not eliminated by the VM, and make the API less error prone. The type system would clearly distinguish the nullable case from the non-null one. Why is javaType() used in record.vm rather than javaUnbox() ? Would it be possible to push a such change into Avro ? Lastly, has anyone investigated the nullable issue for non boxed types ? Would it makes sense to define new options to support @Nullable / @NotNull annotations or Optional ? Clément
