drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paul-rogers <...@git.apache.org>
Subject [GitHub] drill pull request #716: DRILL-5116: Enable generated code debugging in each...
Date Sat, 07 Jan 2017 06:38:16 GMT
Github user paul-rogers commented on a diff in the pull request:

    https://github.com/apache/drill/pull/716#discussion_r95053687
  
    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/compile/ClassBuilder.java
---
    @@ -64,36 +67,33 @@
      * local variables. Have fun!</li>
      * </ul>
      * <p>
    - * Note: not all generated code is ready to be compiled as plain-old
    - * Java. Some classes omit from the template the proper <code>throws</code>
    - * declarations. Other minor problems may also crop up. All are easy
    - * to fix. Once you've done so, add the following to mark that you've
    - * done the clean-up:<pre>
    - * cg.plainOldJavaCapable(true); // Class supports plain-old Java</pre>
    + * Most generated classes have been upgraded to support Plain-old Java
    + * compilation. Once this work is complete, the calls to
    + * <tt>plainOldJavaCapable<tt> can be removed as all generated classes
    + * will be capable.
      * <p>
    - * The setting to prefer plain-old Java is ignored for generated
    + * The setting to prefer plain-old Java is ignored for any remaining generated
      * classes not marked as plain-old Java capable.
      */
     
     public class ClassBuilder {
     
    -  public static final String SAVE_CODE_OPTION = CodeCompiler.COMPILE_BASE + ".save_source";
       public static final String CODE_DIR_OPTION = CodeCompiler.COMPILE_BASE + ".code_dir";
     
       private final DrillConfig config;
       private final OptionManager options;
    -  private final boolean saveCode;
       private final File codeDir;
     
       public ClassBuilder(DrillConfig config, OptionManager optionManager) {
         this.config = config;
         options = optionManager;
     
    -    // The option to save code is a boot-time option because
    -    // it is used selectively during debugging, but can cause
    -    // excessive I/O in a running server if used to save all code.
    +    // Code can be saved per-class to enable debugging.
    +    // Just mark the code generator as to be persisted,
    +    // point your debugger to the directory set below, and you
    --- End diff --
    
    It has not been an issue with Eclipse. I wonder if it will be for IntelliJ? Eclipse cares
about the generated sources only when we step into them. Otherwise, Eclipse completely ignores
the zillions of old generated files that might be lying around. And, since we generate a new
copy of the file each time we generate it, the new copy will replace the old one. Even if
Eclipse had the old file open from a previous session, it will replace the old one with the
new one once Eclipse switches to that window.
    
    Again, I need to look into IntelliJ to see if a more elaborate solution is needed for
that tool.
    
    I like your suggestion to document this. Once all this is committed, I'll submit a JIRA
to add documentation about how to use this, along with the IntelliJ issues, to the Developer
Information page on the Drill web site.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message