avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abayomi Bazuaye <abazu...@vistaprint.com>
Subject RE: Java compiler: unboxed types & nullity
Date Thu, 18 Feb 2016 08:47:02 GMT
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:clement@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

Mime
View raw message