<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    In general, I think that designing something that works well in all
    OpenJDK repos is very difficult, which is why I generally advocate
    more customized libraries.  I have also found it to be logistically
    difficult to design and provide something to satisfy everyone, with
    the added complication that when you update a sharedf test library,
    you risk affecting other tests with unforeseen consequences.<br>
    <br>
    For example, in the langtools world, we are interested in being able
    to work with the error messages from javac, and to exercise
    different invocation modes.   In other repos, you're more likely to
    just be interested in just getting your source code compiled and
    getting an exception if there is a compilation error.<br>
    <br>
    ToolProvider and JavaCompiler are definitely the right building
    blocks to use.   It also helps to have available a method to create
    a JavaFileObject from a string.  ToolBox (that I referred to
    earlier) also has some smarts to derive a filename for a class by
    using regexes to find the package and class declarations.<br>
    <br>
    -- Jon<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 10/20/2014 01:03 PM, Martin Buchholz
      wrote:<br>
    </div>
    <blockquote
cite="mid:CA+kOe0_p19HDmZ+96BRfZf5eo5oJ1zuKcEACAo0AyzfcmKsxOw@mail.gmail.com"
      type="cite">
      <div dir="ltr">So ... I looked at various testing tools in
        openjdk, and I think it would be good if there was easy-to-use
        support this kind of thing available from every jtreg test, but
        the design of such a general utility would be difficult.
        <div><br>
        </div>
        <div>For my own use, I ended up using ToolProvider and
          JavaCompiler, and the result was not bad, but it would be a
          little better if just the right infrastructure was available.</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Oct 15, 2014 at 2:17 PM,
          Jonathan Gibbons <span dir="ltr"><<a
              moz-do-not-send="true"
              href="mailto:jonathan.gibbons@oracle.com" target="_blank">jonathan.gibbons@oracle.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
              class=""><br>
              On 10/15/2014 01:04 PM, Martin Buchholz wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                Occasionally, one would like to generate the java
                sources to be tested instead of checking them in (e.g.
                the generated source files may be huge).  Is there a way
                to do that?<br>
                <br>
                Ideally, you would want to have some java code be @run
                to create the source files, and those could then in turn
                be @compile'd and @run'd, but that does not seem to be
                possible.<br>
              </blockquote>
              <br>
            </span>
            Martin,<br>
            <br>
            We routinely do this in the OpenJDK langtools/test test
            suite, where we have a style of testing that generates
            hundreds, sometimes thousands of classes on the fly, to
            provide the test cases for a feature.<br>
            <br>
            You can generate the Java source code in memory, and then
            use the Java Compiler API to compile it
            (javax.tools.JacaCompiler) either to class files in memory
            or to class files on disk, depending on your ultimate
            usage.  Note if you compile to memory, you can execute the
            classes using an appropriate ClassLoader.<br>
            <br>
            But, this all has to be done within a test class -- there is
            no inherent support in jtreg to @compile and @run generated
            stuff.<br>
            <br>
            You can look at the file langtools/test/tools/lib/ToolBox.java
            for a utility class to facilitate creating in memory source
            objects, compiling them, and so on.  We wrote and used this
            class to replace many of the remaining shell tests in the
            langtools repo.<br>
            <br>
            -- Jon<br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>