More tests and API to set output stream

[Robert Field]

On 02/13/2015 11:55 PM, andrei.eremeev wrote:
>> Hi Robert,
>>
>> Please, find some tests for currentDeclaration() here: 
>> http://cr.openjdk.java.net/~aeremeev/current_declaration.00/
>> The patch is comprised of tests for "Test that replaced Snippets have 
>> null Declarations" and some clean-up.

Thanks.  Will push.

>>
>> Could you clarify what you mean in the following statement?
>>> Test that stack traces have the Snippet id.  assertException is not 
>>> comparing filename, and test should be changed to fetch Snippet.id() 
>>> to compare.
>>> assertException compares actual stack trace with expected one; 
>>> expected stack trace contains golden information about filenames, 
>>> which are Snippet.id(). 
>>
>> ExecutionException does not contain information about Snippet.

Sure.
In a stack trace, for REPL code, the filename is returned as "#" 
followed by the Snippet.id() .
The Snippets and then id() of the elements in the stack trace should be 
retrieved and compared instead of comparing against hard-coded "#1" etc.

>>
>> To test REPL output, I need an ability to set a custom stream writer 
>> to REPL. Currently, all output goes to stdout/stderr. I suggest 
>> adding API to set output stream and using one stream, as it is done 
>> in javac. Thus, tests for tool will look like:
>>     REPL.start(input, output, args);
>>     // checking output stream.
>> Please, find prototype of this feature in attachments. What do you 
>> think about it?

I see what you are getting at.  You want an in-process tool testing 
approach.  That is reasonable.  I was assuming remote-launch and output 
grabbing would be used.
There are problems with this prototype:  Changes are made to the remote 
agent, it is in a separate process and will not see these changes.
The prints in the remote code, as are most of these prints, targets of 
this TODO item:
   * Remove all prints from API implementation, making them API 
exceptions or return values as needed.
The prototype merges all output, whether previously sent to out or to 
err into one writer.  It also, unnecessarily adds a new layer of 
indirection, through a Writer.
Rather than collapsing, you could retain more information by maintaining 
the separate channels.
Since this is so tied to the above issue I need to address, I'll 
implement a first pass.

-Robert

>>
>> Andrei Eremeev
>