JEP 495 Question

[Brian Goetz]

Here's the bar we're envisioning: methods that are automatically 
imported in this way _effectively become part of the langauge_.  The bar 
for that is very high.

println(String) clears that bar; a language without console output is 
pretty suspect. 
readSomeCharsAndParseThemAsAnIntegerAndLeaveTheInputInSomeUnspecifiedState() 
does not.

This doesn't mean there can't be something _elsewhere in the JDK_ for 
this purpose, or even many somethings.  But if you couldn't credibly say 
"this should be part of every language", then it almost surely does not 
meet the bar for IO.

But these methods are so flawed that they obviously fail this bar.  
(And, they also serve as great "my first method" examples, for students 
learning simple abstraction!)





On 11/7/2024 4:00 PM, Tagir Valeev wrote:
> Hello!
>
> I agree that methods like readInt and readDouble should be added, if 
> we really want to make Java appealing for beginners who try to write 
> console applications. It looks to me that sometimes we think too much 
> and avoid making decisions and taking responsibility if there's no 
> single obviously good way to solve the problem. Here any decent 
> solution would be good enough, were it just a shortcut to 
> parseDouble(readln()) or having a Scanner.nextDouble under the hood. 
> Either way is much better than having no solution at all. Students 
> will get used to it, and we can easily ignore nitpickers who would 
> criticize it and insist that the opposite solution should be 
> implemented. Because nitpickers will do this in any case.
>
> I personally would prefer even more beginner-friendly solution, like 
> repeatedly asking for a number and displaying a friendly error message 
> if the user types something different (without throwing an exception). 
> Sure, this is not flexible and should not be used in 
> production-quality applications. But this is what would be the least 
> scary for beginners.
>
> I also see the desire to keep the API surface not bloated, but you can 
> see how many people connected to education actually requested methods 
> to read numbers in this mailing list. Do you remember them requesting 
> anything else? To me it's clear that reading numbers in a one method 
> call is a single most wanted addition to IO. You'll see many more such 
> requests after the feature is graduated (well, unless every single 
> student moves to Python).
>
> With best regards,
> Tagir Valeev
>
> On Thu, Nov 7, 2024 at 9:47 PM Kenneth Fogel 
> <kfogel at dawsoncollege.qc.ca> wrote:
>
>     I understand your position and ten years ago I would agree with it
>     wholeheartedly but not anymore. I am excited about JEP 445 and how
>     it might bring more students and self learners to Java. Today’s
>     learners want fast results. It is why I believe so many are hooked
>     on Python. I dislike Python because it is an untyped language, but
>     we cannot ignore that:
>
>     Python: loan = input("Loan: ")
>
>     makes more sense to those starting out than:
>
>     Java: var loan = Double.parseDouble(readln("Loan: "));
>
>     Both will throw exceptions if you enter “bob” for the value, just
>     at different points in the execution.
>
>     I feel that any language should evolve not only with new features
>     but in new ways to learn that match how people learn today. I do
>     agree that there can easily be a flood of requests that could
>     probably make Java look like GW-BASIC.
>
>     Thank you, Brian, for providing the summary of why you and the
>     Java team decided not to have a numeric read. As they say, we will
>     have to agree to disagree.
>
>     Ken
>
>     *From:*amber-dev <amber-dev-retn at openjdk.org> *On Behalf Of *Brian
>     Goetz
>     *Sent:* November 7, 2024 2:41 PM
>     *To:* Barry Burd <bburd at drew.edu>; amber-dev at openjdk.org
>     *Subject:* Re: JEP 495 Question
>
>     Yes, these were considered, and dismissed with prejudice, in part
>     because the model implied by readInt and readDouble is a
>     problematic one, because it greatly complicates the "reading
>     state" that has to be understood by the user (e.g., what if
>     there's no digits on the line, does it read another line?  what if
>     the digits end mid-line, does it leave the cursor there?  what if
>     it consumes all the characters on the line, and then you read a
>     string?)  These are issues that invariably trip up beginners and
>     experienced users alike.
>
>     The locution you suggest, which is to use readln() to read a line
>     into a String, then parseInt() to convert to an int, is more wordy
>     than some of the alternatives, but much clearer and simpler as to
>     what is going on, because it composes two simple functions (read a
>     string, convert a string to an int).  This is good for beginners,
>     because they can see that there are steps here to get the data
>     into the form they want.  The readInt() method provides the
>     illusion of simplicity, but ends up moving significant complexity
>     to where we are more likely to trip over it in the dark.
>
>     I'm not saying there will never be a richer way to do this, but
>     readInt() and friends are definitely not it.
>
>     More generally, one of the worst things about creating an IO class
>     is that it immediately becomes target for a flood of "can you just
>     add my one favorite method" requests.  We might add a few more
>     methods to it in the next decade.  But we also might not; less is
>     more.
>
>     On 11/7/2024 12:06 PM, Barry Burd wrote:
>
>         I see that parameterless println() and readln() methods are
>         being added to java.io.IO
>         <https://urldefense.com/v3/__http://java.io.IO__;!!ACWV5N9M2RV99hQ!MJpHobvTKPnFT329pXDoV-I9JfQsit7ze1tw661KBZ8lDiF51A0FsvGAY09VGmeRu2tKtLPzDUKSvyjI$>
>         in JEP 495. I'm still wondering if there's been any thought to
>         including methods like readInt and readDouble. In the early
>         stage of an introduction to Java, it's common to have the
>         student input int values and double values for simple
>         examples. With the current spec, the best way to do this (as
>         far as I can see) is
>
>               var n = Integer.parseInt(readln("Enter a number"));
>
>         It seems natural to simplify this with a readInt method, and
>         the addition of such a method wouldn't weigh heavily on the
>         java.io.IO
>         <https://urldefense.com/v3/__http://java.io.IO__;!!ACWV5N9M2RV99hQ!MJpHobvTKPnFT329pXDoV-I9JfQsit7ze1tw661KBZ8lDiF51A0FsvGAY09VGmeRu2tKtLPzDUKSvyjI$>
>         package.
>         Any thoughts?
>           --Barry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241107/f8e08a87/attachment-0001.htm>