JEP 477 Interacting with the Console

David Alayachew davidalayachew at gmail.com
Mon Jul 15 21:27:28 UTC 2024


As long as readInt and friends consume the entire line, I'm fine with that.

I see no value in exit. So many of the students I helped tutor treated that
like a crutch, and they had to be dragged away from it. In fact, I think I
did too. That is basic control flow that should be treated as unavoidable
complexity. Same as basic arithmetic and concatenation.

As for Math, what's stopping us from static importing Math too? No need to
reinvent the wheel if it works well enough.

On Mon, Jul 15, 2024, 12:00 PM Cay Horstmann <cay.horstmann at gmail.com>
wrote:

> I'd like to raise one more time the issue of simple console interaction.
>
> https://openjdk.org/jeps/477#Interacting-with-the-console puts up the
> strawman of
>
> try {
>      BufferedReader reader = new BufferedReader(new
> InputStreamReader(System.in));
>      String line = reader.readLine();
>      ...
> } catch (IOException ioe) {
>      ...
> }
>
> I don't think it is convincing to cite BufferedReader. I looked up the top
> five intro to Java books that make up the bulk of US college market. All
> use Scanner, not BufferedReader. It is easy to see why:
>
> * No checked exceptions
> * Can read numbers
>
> Scanner has issues (mixing nextInt/nextLine, localized number input vs.
> non-localized print), so I could, as an author and teacher, be convinced to
> change to something better.
>
> The appeal of short print/println/readln methods seems obvious. But now
> consider number input:
>
> int age = Integer.parseInt(readln("How old are you?"));
>
> A beginning student must realize in the first week or so of instruction:
>
> * There are static and instance methods
> * A static method can be
>    * qualified by a class
>    * unqualified due to static import
>    * one of the static methods that is magically imported
>      * but only in a source file containing an implicit class
>
> That's not conceptually simple.
>
> If the static methods that a beginner needs in the first few weeks
> (including parseInt, parseDouble, exit, and a handful of the Math methods)
> were all unqualified, then the beginner would be helped. Otherwise, you
> would help the beginner more by not statically importing IO by default.
> They can start out with IO.println, have a consistent mental model in those
> first few weeks, and learn static imports later.
>
> Or, if the focus is not the beginner, but the author of small programs,
> the JEP could state that as the motivation.
>
> In general, the needs of beginners and authors of small programs are not
> the same. The JEP bounces between the needs of the two. Implicit classes
> are useful for both, but magic imports will add puzzlement for beginners.
>
> Cheers,
>
> Cay
>
> --
>
> Cay S. Horstmann | https://horstmann.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240715/2360e7da/attachment.htm>


More information about the amber-dev mailing list