RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
christoph.langer at sap.com
Tue Sep 4 13:22:55 UTC 2018
thanks for your feedback (and thanks of course to all the others who commented on this proposal).
As I've written in my first mail, this request came up because we had implemented getWidth/getHeigth APIs for console windows in our licensed VM to be used in a certain usage scenario. Now we are in the process of moving this user to an OpenJDK based VM and thought these APIs might be candidates for contribution as general purpose API. Looking at java.io.Console, it seemed the APIs would fit in there. We also thought that there could be further additions to this class.
However, we had not been aware of the history of java.io.Console and we also did not know jline project nor that it was adopted by the OpenJDK into jdk.internal.le for usage by jshell and nashorn. Thanks for pointing this out. After exploring this a bit, I'm at a point where I would go to our user and ask them to try jline. I'm quite sure they'll be able to adopt it.
Regardless of that, isn't it still worth to gradually enhance java.io.Console over time? I don't know whether we'd eventually get to a point where jline could be replaced for jshell but maybe that could be a long term goal.
If we can agree to evolve java.io.Console, I'll continue with my work for width/height APIs. But if it's consent to keep java.io.Console in its limited current state, I would also be willing to withdraw this request.
What's the way to go?
> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Montag, 27. August 2018 13:30
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Baesken, Matthias
> <matthias.baesken at sap.com>
> Subject: Re: RFR: 8209937: Enhance java.io.Console - provide methods to
> query console width and height
> On 24/08/2018 14:18, Langer, Christoph wrote:
> > Hi Rémi, Hi Peter,
> > thanks for your quick answers.
> > What you've suggested, Rémi, is perfectly right. I've updated my webrev.
> The methods were copied from our old implementation (of a different class)
> where they were provided as static.
> > I will also think of using an optional. I'm furthermore wondering if we
> should provide a method "dimensions()" returning an (optional)
> java.io.Console.Dimension object that contains both height and width...
> > Here is a new webrev:
> I'm in two minds as to whether this API is the right thing to do. Can
> you expand a bit on how you are using them? There have been several
> requests for additions to the Console API over the years, mostly to
> support formatting or exposing the console encoding, but I don't recall
> anyone looking for the dimensions. Roger is right that it's a bit of a
> slippery slope. As I recall, java.io.Console was deliberately minimized
> for Java SE 6 to focus on password input and avoid introducing an
> extensive API. In the mean-time, the additional of jshell has exposed
> some of the shorting comings and maybe we should look at exposing just
> enough to support that type of use-case (editing and line history mostly).
> As regards the proposal then I think the API docs will need fleshing out
> to define what height and width as the current javadoc isn't clear if it
> means bytes, characters, pixels in whatever font is used for the
> console, or something else. In addition, the javadoc would need to be
> clear that it's just a snaphot of the dimension as it can change at any
More information about the core-libs-dev