You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Philip Zeyliger (JIRA)" <ji...@apache.org> on 2009/12/30 20:09:29 UTC

[jira] Updated: (AVRO-269) Use system compiler to test SpecificCompiler's generated code.

     [ https://issues.apache.org/jira/browse/AVRO-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philip Zeyliger updated AVRO-269:
---------------------------------

    Attachment: AVRO-269.patch.txt

The attached patch adds code to invoke the System compiler to check that generated code
is valid.  In the course of adding these tests, I found a few minor bugs in
relation to inconsistent capitalization and mangling.  I decided to remove
capitalization altogether (a schema named "foo" becomes "class foo"), because
that seemed more transparent and consistent.  There were a couple of instances
where names weren't being mangled, which the tests caught.

Once concern is that this adds about 6 seconds to the running time of all the
tests.  I've gone about it a bit pedantically, and am compiling every darn
schema in TestSchema...  Removing that would chop 5 seconds off, which may
be a reasonable compromise.

I had a fair amount of hassle getting the system java compiler to work in ant's
test runner.  The issue is that, by default, the compiler uses the current
classpath.  With the junit ant task, the classpath only has ant's stuff.  Ant
adds other stuff at runtime.  I was able to deal with this by adding
'fork="yes" forkMode="once"' to the junit task works.  Without "once" it's
miserably slow, but with "once" it seems fine.  It should have been
possible to add a "sysproperty" to the task to pass through test.java.classpath,
and use Arrays.asList("-classpath", System.getProperty("...", System.getProperty("java.class.path")))
(the "default" to java.class.path is convenient for other JUnit runners,
like Eclipse's) as the fourth argument to compiler.getTask(), but I couldn't
get 'sysproperty' to dereference a path reference inside the build.xml.

I've gone back and forth on actually creating files to compile them.
There's a trick (inheriting from SimpleJavaFileObject) to keep the source
files in memory.  Though it works, the output files ended up in my
source directory, and debugging was harder (what do you do when you
get a compile error), so I went back to using real files.

> Use system compiler to test SpecificCompiler's generated code.
> --------------------------------------------------------------
>
>                 Key: AVRO-269
>                 URL: https://issues.apache.org/jira/browse/AVRO-269
>             Project: Avro
>          Issue Type: Test
>          Components: java
>            Reporter: Philip Zeyliger
>            Assignee: Philip Zeyliger
>            Priority: Minor
>         Attachments: AVRO-269.patch.txt
>
>
> Using the javax.tools API (http://java.sun.com/javase/6/docs/api/javax/tools/JavaCompiler.html),
> it's possible to test SpecificCompiler's
> generated code by compiling it.  Doing so caught a couple of
> bugs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.