cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
Date Tue, 11 Nov 2014 10:27:34 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206249#comment-14206249
] 

Robert Stupp commented on CASSANDRA-8241:
-----------------------------------------

bq. scope of the problem

IMO people are used to rely on Java language's boxing and implicit casts and it would cause
(just) usability issues when these features are not there.

For example the "stupid" {{sin}} function is easier to read with boxing. 

{code:title=javac/ecj}
return input != null ? Math.sin(input) : null;
{code}
{code:title=javassist}
return input != null ? Double.valueOf(Math.sin(input.doubleValue())) : null;
{code}

Complexity increases with the number of arguments and when UDTs/tuples/collections are possible.

In addition we could easily allow new Java 8 language features (e.g. lambdas and streaming)
within UDFs (currently restricted to Java 7) - could for example simplify source code working
on collections passed to UDFs.

bq. some other place where we use it?

I could imagine to use user-provided code for triggers. But current trigger implementation
works at a "lower level" - so (I guess) that would be a re-implementation of triggers on CQL3
level.
Maybe custom 2i providers could also use user-provided source code - but since these usually
require custom libs, it does not feel suitable.

> Use javac instead of javassist
> ------------------------------
>
>                 Key: CASSANDRA-8241
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8241
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Robert Stupp
>            Assignee: Robert Stupp
>              Labels: udf
>             Fix For: 3.0
>
>         Attachments: 8241-ecj.txt, udf-java-javac.txt
>
>
> Using JDK's built-in Java-Compiler API has some advantages over javassist.
> Although compilation feels a bit slower, Java compiler API has some advantages:
> * boxing + unboxing works
> * generics work
> * compiler error messages are better (or at least known) and have line/column numbers
> The implementation does not use any temp files. Everything's in memory.
> Patch attached to this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message