[
https://issues.apache.org/jira/browse/DRILL-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762509#comment-15762509
]
ASF GitHub Bot commented on DRILL-5052:
---------------------------------------
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/660#discussion_r93134337
--- 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 --
As we've discussed, this is the class loader, not the global class cache.
The non-ASM path can't get the class name from the byte codes, so the compiler
has to tell us, via this map, which byte code corresponds to which compiled
class name. The "plain old Java" class loader then fetches classes given their
compiled names using this map.
> 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)
