<div dir="auto">I feel like I have to disagree here. "Growing" is not about jumping from console calculator to spring boot aot compiled microservices with distributed tracing and other buzzwords. It is about jumping from one-file console calculator to n-files console calculator, assume on the stage of introducing packages and imports.<div dir="auto"><br></div><div dir="auto"> IO will be used in production as often as System.console() (never, I would say), because modern logging and debug tools are just more convenient. All of this is my opinion, I am not stating it as a fact, hovewer I am strongly convinced in all of the above.</div><div dir="auto"><br></div><div dir="auto">And once again, production code is completely different world, and anything that is locked inside classes a that are not even allowed to have a package is not going to have any affect on people that are getting familiar with modern web, just because of how far this points are in learning path</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2024, 11:21 Stephen Colebourne <<a href="mailto:scolebourne@joda.org" target="_blank" rel="noreferrer">scolebourne@joda.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 7 Nov 2024 at 21:10, Brian Goetz <<a href="mailto:brian.goetz@oracle.com" rel="noreferrer noreferrer" target="_blank">brian.goetz@oracle.com</a>> wrote:<br>
> 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.<br>
<br>
Making a method like readInt() "effectively part of the language" is<br>
clearly wrong. And therefore obvious why it should be rejected.<br>
But maybe the answer is to take a step back and reconsider whether the<br>
"automatically imported" part of the sentence is a bad choice (which<br>
therefore nullifies the "effectively become part of the language"<br>
claim, effectively allowing readInt and friends).<br>
<br>
The JEP ("Growing a program" section) asks users that migrate from a<br>
simple source file to a normal one to add two imports:<br>
  import static java.io.IO.*<br>
  import module java.base<br>
<br>
I'm OK with `import module java.base`, but I'm afraid I think `import<br>
static java.io.IO.*` is a really terrible idea. Most production code<br>
should not be using the console at all, it should be using some kind<br>
of logging system. System.out is a hack. IMO, the "growing the<br>
language" approach described in the JEP will end up over time<br>
normalising console output in the minds of developers, with a negative<br>
effect on production Java code.<br>
<br>
Given this, and working backwards (IMO):<br>
- Encouraging `import static java.io.IO.*` is a Really Bad Idea<br>
- Therefore migrating from simple source file should therefore only<br>
require `import module java.base`<br>
- Therefore, simple source files should use IO.println(String), not<br>
just println(String)<br>
- Therefore, more methods can be freely added to IO, like readInt()<br>
<br>
Yes, yes, yes. I know. `IO.println(String)` is more complex than just<br>
`println(String)` for a beginner. But is it really that bad for a<br>
beginner given the risk of normalising console usage?<br>
<br>
Stephen<br>
</blockquote></div>