JShell API questions / feedback

[Robert Field]

On 01/26/16 06:28, Roy van Rijn wrote:
> Dear kulla-dev's,
>
> I've been working on a project to incorporate the JShell API into an
> environment to help teach the Java language to absolute beginners
> (mainly kids).

Cool!

>
> For this I'm using the JShell API and making my own editor. The eval()
> results have to be parsed and evaluated by my code. But I've ran into
> a few issues (or maybe just questions).
>
> First, I need to process the Snippet output. One thing I've noticed is
> that the Snippet API is rather limited. Image you create a method and
> receive a MethodSnippet. Now I want to know the return type of this
> method for further processing, how do I get to this? The only thing
> I've currently found is:
>
> MethodSnippet snippet = ...;
> String returnType =
> snippet.signature().substring(snippet.signature().lastIndexOf(')') +
> 1);

That looks about right.

>
> Do I have to parse the signature myself to get to the return type?
> This seems rather odd.

What do you use the return type for?

> Also, in the API there seems to be a lot of
> String-usage. Instead of returning the actual type everything is a
> String. I think I'd rather love to see the API returning classes and
> objects. For example the 'value' of something that has been evaluated
> now is always a String (the toString() of the object is called)
> instead of the actual object. I'd rather have the API returning the
> object and the JShell terminal calling toString() on it for display
> purposes. Would this be possible? IMHO that would be a much better
> API. The same si true for the mentioned returnType, I'd love to have
> it return a class instead of a string.

Understood.  It would be richer to have Object.
The process executing the snippets is remote, so there is no way to 
return through the API that nice FooBar object that was just created on 
the remote side.
The only thing I could imagine is to return some proxy object that you 
could query, but that would be awkward when the main focus is textual 
input and output.

>
> Also, one other thing I've noticed is that the method names used in
> the API are not following the bean-spec, for example to get fields
> from a snippet you have to call snippet.name() and snippet.typeName().
> This seems very odd compared to most Java JDK code. I would have
> suspected snippet.getName() and snippet.getTypeName(). Is this a new
> preferred way of writing methods in a JDK API? Will we see this in
> other API's as well? Call me old-fashioned but I personally rather
> just have the getters.

There are and have been, for a very long time, two schools of thought in 
JDK world about "get" prefixes, in one you use a "get" prefix on all 
accessors, in the other, I think the predominant, you prefix with "get" 
only when there is a corresponding "set", see, for example Map:
    https://docs.oracle.com/javase/8/docs/api/java/util/Map.html
The queries are entrySet(), keySet(), size(), and values(), not 
getEntrySey(), getKeySet(), getSize(), and getValues().  Or to go deeper 
into core, length() on String, and hashCode() on Object.

>
> I'd love to hear what other people think about the current API design,
> am I the only one bothered by this? Or am I using it the wrong way, or
> missing the point?

PLEASE do give feedback on the API!  The best APIs have had plenty of 
feedback, while still maintaining consistency.

Thanks,
Robert

>
> Roy