You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filing this ticket to investigate if we can have support for java.lang primitive types.
Today we have limited set of specialized primitive datatypes e.g StdString, StdLong, StdInt. These specialized types have no methods associated with them and are inferior to standard JVM types like String, Int and Long. A user writing a UDF with a primitive type arg will always want to use the standard jvm type, since they are easy to work with having a set of familiar methods (e.g consider the String class) and everyone understands them better [e.g String, Int, Long are very well understood and used throughout].
Also, as and when we add support for newer primitive datatypes, it will become more challenging to roll our own wrapper classes for Decimal, Date, Binary etc.
There is no performance concern here as users working on primitive types will always 'realize' the underlying primitive object into a standard jvm type. The performance may also be slightly better as we are not creating wrapper classes for them.
Filing this ticket to investigate if we can have support for java.lang primitive types.
Today we have limited set of specialized primitive datatypes e.g
StdString
,StdLong
,StdInt
. These specialized types have no methods associated with them and are inferior to standard JVM types likeString
,Int
andLong
. A user writing a UDF with a primitive type arg will always want to use the standard jvm type, since they are easy to work with having a set of familiar methods (e.g consider theString
class) and everyone understands them better [e.g String, Int, Long are very well understood and used throughout].Also, as and when we add support for newer primitive datatypes, it will become more challenging to roll our own wrapper classes for
Decimal
,Date
,Binary
etc.There is no performance concern here as users working on primitive types will always 'realize' the underlying primitive object into a standard jvm type. The performance may also be slightly better as we are not creating wrapper classes for them.
I've tried a prototype for Spark using standard JVM primitive types as shown here https://github.com/rdsr/t2/blob/master/examples/src/main/java/t2/examples/Add.java and the results look encouraging. The code is also much easier to read [without the specialized primitive wrapper]
The text was updated successfully, but these errors were encountered: