[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385511#comment-14385511 ] Robert Stupp commented on CASSANDRA-8241: - EPLv1.0 is mentioned here https://www.apache.org/legal/resolved.html#category-b. Apache Tomcat uses ecj in its distribution ([NOTICE|https://github.com/apache/tomcat/blob/trunk/NOTICE] + [LICENSE|https://github.com/apache/tomcat/blob/trunk/LICENSE]). TBH I probably don't understand the english license text to all its extent. It *looks* to be ok - but I'm not 100% sure. 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383859#comment-14383859 ] Sylvain Lebresne commented on CASSANDRA-8241: - For what it's worth, I do think the lack of auto-boxing will be a pain in the ass. Not to say that I have the perfect solution. 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[
https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383933#comment-14383933
]
Robert Stupp commented on CASSANDRA-8241:
-
Using Oracle's {{JavaCompiler}} API implementation requires installation of a
JDK (not a good option).
We can bundle the Eclipse thing (which btw also implements the {{JavaCompiler}}
API beside its native API.
I see three options for this one (preferably option 3):
# stick with javassist (effectively resolving this ticket as 'later')
# use ecj with its native API (stick with ecj)
# use ecj with {{JavaCompiler}} API (allows to use ecj and JDK)
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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383950#comment-14383950 ] Aleksey Yeschenko commented on CASSANDRA-8241: -- Before going any further w/ Eclipse, make sure we can bundle it at all, license-wise. Eclipse Distribution License is ASF-compatible (see https://www.apache.org/legal/resolved.html#category-a), but there is nothing there about Eclipse Public License. I'm not sure which one the Eclipse thing is covered by, but if it's not EDL, it might have to be vetted, though ultimately I expect it to be compatible. 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383972#comment-14383972 ] Robert Stupp commented on CASSANDRA-8241: - Damn - yes, EPL is nod EDL. Probably EPL1.0 is not compatible with ASF2.0 (according to [this comparison|https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses]). Tried to find a definitive answer on the web but had no luck. 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383979#comment-14383979 ] Jonathan Ellis commented on CASSANDRA-8241: --- Probably best to ask the legal team. https://issues.apache.org/jira/browse/LEGAL 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14206161#comment-14206161 ] Robert Stupp commented on CASSANDRA-8241: - ecj.jar is just the java compiler - there are no more dependencies required. I think the Eclipse compiler is fine and used by other projects (e.g. Tomcat). OTOH we could also support both javac + ecj since ecj supports the Java Compiler API - but that would add complexity in dev + ops. So I'm not sold on that. Not sure whether pulling in some source template makes code generation easier to read/maintain since we have several replacements that use variable argument lists. But I try that. Sure - allowing user-provided source code integration is painful. We can add some support to help users not to accidentally add bad code. Just thought about some library/tool that users can use (just created CASSANDRA-8289 for that). 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14206166#comment-14206166 ] Benjamin Lerer commented on CASSANDRA-8241: --- I think it would be good to define a bit more the scope of the problem. My understanding is that so far we only use code generation for UDF. Is there some other place where we use it? If not, I think it would be nice to have something better that javassist, but it is only a nice to have and we can stick with javassist for now. From a benefits/problems point of view it looks as the best choice. 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[
https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14206311#comment-14206311 ] Benjamin Lerer commented on CASSANDRA-8241: --- It is a nice to have, but in my opinion it does make a big change. So I would stick with javassist for now and look at it in the future if some users are really pushing for it. 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14205584#comment-14205584 ] Jonathan Ellis commented on CASSANDRA-8241: --- How do you evaluate the goodness of eclipse vs javassist? /cc [~dbrosius] [~blerer] 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14205958#comment-14205958 ] Dave Brosius commented on CASSANDRA-8241: - TBH, not a big fan of either solution, each is nasty in its own right. I agree with Robert, using Java Assist means you will always be in a state of catch up language wise. But relying on eclipse means dragging an elephant of configuration test matrix problems around with you forever. I'm also not a big fan of building prototype java code up in StringBuilders. Can we externalize the prototype into a first class file that get's getResourceAsStream'ed in and modified thru markers of some sort? 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194868#comment-14194868 ] Jonathan Ellis commented on CASSANDRA-8241: --- This may still be a good idea, but doesn't this mean users need to deploy a JDK (which has stricter license requirements) and not just a JRE? 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: 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)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14195181#comment-14195181 ] Robert Stupp commented on CASSANDRA-8241: - bq. users need to deploy a JDK Yes - tools.jar is required so the stricter license requirements apply. Not sure what these stricter license requirements exactly mean - my knowledge is about that is quite old - as far as I remember the stricter license forbids redistribution of a bundled JDK. JDK requirement itself seems similar to what JEE containers require e.g. for JSPs. Tomcat uses the Eclipse compiler - which could be another option. I'm pretty much in favor of using either tools.jar or Eclipse compiler to support known Java language features which are missing in javassist. Will dig a bit more into the license foo and check the Eclipse compiler. 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: 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)
