Steps towards integrating Kulla into JDK9

[Brian Goetz]

This looks good to me (assuming the commas in the tables are supposed to 
be dots?)

On 4/23/2015 5:48 PM, Robert Field wrote:
> Ah, so we want a green bikeshed ;-)
>
> Where does this put naming?  How about this?
>
> Module
> 	jdk.jshell
> Tool launcher
> 	jshell
> API Package
> 	jdk.jshell
> Implementation Package
> 	jdk.internal.jshell,impl
> Remote Package
> 	jdk.internal.jshell,impl.remote
> Tool Package
> 	jdk.internal.jshell,tool
>
>
> Please can we have a full round of yea or nay -- we don't want to go
> around on this any more.
>
> Thanks,
> Robert
>
> P.S. While I'm worried about skewing perceptions and conceptually
> muddying the image of
> the API (particularly for IDE vendors who we hope to enlist to use the
> API), I have to
> agree with Maurizio, Mark, and Brian that "eval" or any variation
> thereon is very vague.
> Plus the API's target audience is small, smart, and easily educated.  A
> single unique
> "brand" works better than two.  So, no bikeshedding from me.
>
>
> On 04/23/15 13:59, mark.reinhold at oracle.com wrote:
>> 2015/4/23 1:51 -0700,brian.goetz at oracle.com:
>>> I guess we've got us a bikeshed :)
>>>
>>>> As to the name of the package, that depends where the center is.  For
>>>> someone wanting to look at how the tool is implemented jdk.jshell would
>>>> be right. For an IDE using the evaluation API, jdk.eval or something
>>>> like that would be appropriate. I think eval applies to both, but jshell
>>>> only applies to the tool.
>>> While this argument would surely hold up in court, I think the notion of
>>> "tool backed by a library" is one that is entirely understandable to
>>> people, and "jdk.jshell" is much more evocative of what it does than
>>> "jdk.eval".  I worry that we're sacrificing usability for correctness in
>>> this choice of name.  We want people to be able to look at the module
>>> names in the module graph and be able to have an idea of what it does.
>> I agree.  "jdk.jshell" is a better name for the module, and for the
>> packages that it exports.  "eval" is just way too generic, and "repl"
>> is a somewhat specialized term (not to us, but to the 9 million).
>>
>> - Mark
>