[
https://issues.apache.org/jira/browse/DRILL-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762421#comment-15762421
]
ASF GitHub Bot commented on DRILL-5052:
---------------------------------------
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/660#discussion_r93127937
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/JaninoClassCompiler.java
---
@@ -58,5 +56,27 @@ public JaninoClassCompiler(ClassLoader
parentClassLoader, boolean debug) {
}
@Override
+ public Map<String,byte[]> compile(final ClassNames className, final
String sourceCode)
+ throws CompileException, IOException, ClassNotFoundException {
+
+ ClassFile[] classFiles = doCompile(sourceCode);
+ Map<String,byte[]> results = new HashMap<>();
+ for(int i = 0; i < classFiles.length; i++) {
+ ClassFile classFile = classFiles[i];
+ results.put(classFile.getThisClassName(), classFile.toByteArray());
--- End diff --
Will it defeat the purpose of caching the compiled class, if the key in the
cache is the class name? The class name, if I understand correctly, is like
org.apache.drill.exec.test.generated.ProjectGenNNN, where NNN is a sequence
number. It's possible that two queries may require same generated code, but
with different sequence number. Using class name this way seems to indicate
multiple copies of code would be complied.
For now, it is fine if the purpose is for adding debugging option using
plain-old class. But it may cause some performance overhead, in the future.
> Option to debug generated Java code using an IDE
> ------------------------------------------------
>
> Key: DRILL-5052
> URL: https://issues.apache.org/jira/browse/DRILL-5052
> Project: Apache Drill
> Issue Type: Improvement
> Components: Execution - Codegen
> Affects Versions: 1.8.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Priority: Minor
> Labels: ready-to-commit
>
> Drill makes extensive use of Java code generation to implement its operators.
> Drill uses sophisticated techniques to blend generated code with pre-compiled
> template code. An unfortunate side-effect of this behavior is that it is very
> difficult to visualize and debug the generated code.
> As it turns out, Drill's code-merge facility is, in essence, a do-it-yourself
> version of subclassing. The Drill "template" is the parent class, the
> generated code is the subclass. But, rather than using plain-old subclassing,
> Drill combines the code from the two classes into a single "artificial"
> packet of byte codes for which no source exists.
> Modify the code generation path to optionally allow "plain-old Java"
> compilation: the generated code is a subclass of the template. Compile the
> generated code as a plain-old Java class with no byte-code fix-up. Write the
> code to a known location that the IDE can search when looking for source
> files.
> With this change, developers can turn on the above feature, set a breakpoint
> in a template, then step directly into the generated Java code called from
> the template.
> This feature should be an option, enabled by developers when needed. The
> existing byte-code technique should be used for production code generation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
