RFR 8172102: jshell tool: remove print method forwarding to System.out from default startup

[Brian Goetz]

The readFile() method still uses paths, though the only call appears to 
provide a single file name.  Could replace with readSingleFile().

At #1677, comparing the expanded startup to the *contents* of the 
default seems questionable, but unlikely to actually cause harm.

Otherwise, +1.


On 12/30/2016 3:34 PM, Robert Field wrote:
> Thanks for the comments!
>
> Addressing the concerns....
>
> Use of path-separator removed.  Now multiple uses of --startup.
> Make changes (sub-task) included below.
> Dynamically generated includes removed.  Fixed JAVASE added.
> JDK 10 bug added for build-time generation:
>        https://bugs.openjdk.java.net/browse/JDK-8172154
>
> Main bug::
>     jshell tool: remove print method forwarding to System.out from 
> default startup
>     https://bugs.openjdk.java.net/browse/JDK-8172102
>
> Sub-task bug:
>     jshell tool (make): include built-in startup scripts in image
>     https://bugs.openjdk.java.net/browse/JDK-8172155
>
> Langtools webrev:
>     http://cr.openjdk.java.net/~rfield/8172102v2.webrev/
>
> Top level webrev:
> http://cr.openjdk.java.net/~rfield/8172155v2.webrev/make/CompileJavaModules.gmk.sdiff.html 
>
>
> -Robert
>
> On 12/30/16 10:17, Brian Goetz wrote:
>> I think the use of path syntax here is a bit of an abuse.  Typically, 
>> a path A:B represents a search path; first look in A, and then, if 
>> not found, look in B.  But what you want to indicate is that we 
>> should process A *and* B at startup; this isn't a path.
>>
>> Unfortunately, there's not a universally accepted "and" character, 
>> where you could say "A,B" or "A+B" that people would immediately 
>> grok.  So better to use repeated flags:
>>
>>     jshell --startup A --startup B
>>
>> which is a bit verbose, but I think is more standard.
>>
>> I'd also prefer to see the standard startup be an actual, checked-in 
>> file called something like resources/DEFAULT.jsh, which is placed in 
>> the output directory alongside classfiles through the usual build 
>> mechanics, rather than living in code. I don't see that in the webrev?
>>
>