Question about IO.println

Stuart Marks stuart.marks at oracle.com
Fri Mar 7 21:14:40 UTC 2025


Hi,

Our goal with the IO class is to have it add as few mechanisms as possible. Anything 
it can do, one should easily be able to do with existing classes like PrintStream or 
BufferedReader. So, we wouldn't add a varargs method to IO itself without having one 
in PrintStream or something.

Now, should PrintStream have a varargs overload of println? Well, println first 
appeared in JDK 1.0 well before varargs existed and the answer then was to use the + 
string concatenation operator for multiple values. This still works, though there 
are cases where it doesn't work very well.

When varargs was added (5.0) PrintStream got printf with varargs, but println wasn't 
retrofitted with varargs.

And there will be string templates, which will allow one to embed multiple values 
unobtrusively, so there's no need for varargs here. And a string templates should be 
directly usable from IO.println, so it'll come for "free".

Thus I don't see a need to add varargs overloads here.

s'marks



On 3/4/25 5:03 AM, David Alayachew wrote:
> Hello Amber Dev Team and Core Libs Dev Team,
> 
> Another reddit discussion popped up today about IO.println(), and one of the 
> comments mentioned that they wanted something along the lines of this.
> 
> IO.println(num1, num2, num3); //prints out "1 2 3"
> 
> I proposed that maybe a better option would be a String.join overload. So, instead 
> of String.join(String delim, String... elements), there would be String.join(String 
> delim, Object... elements), with each object getting toString() called on it.
> 
> What are your thoughts on either of these ideas? I actually think the IO.println() 
> version is nice, but I felt like String.join made a slightly better compromise.
> 
> Another commentor mentioned that this will be easier with String Templates too, so 
> maybe it is better to wait for that. I don't think String templates are a bad idea 
> here, but it also felt like overkill imo. A library function seems like a better fit.
> 
> Thank you for your time and thoughts.
> David Alayachew



More information about the core-libs-dev mailing list