RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
Hi, please review and give feedback for this augmentation of java.io.Console. We have users that have the need to query for Width and Height of the console device in Java. In our own JVM implementation we had given them this hook as a custom extension already quite some time ago. We think, however, that it is a worthwhile augmentation of java.io.Console. Bug: https://bugs.openjdk.java.net/browse/JDK-8209937 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/ I'll also open a CSR for this, but I'll wait for some feedback on our proposal first. Thanks & Best regards Christoph
Hi Christoph, getWidth() and getHeight() should be instance methods and not static methods, providing the weight or the height if there is no console seems weird. Also, they should be named width() and height() given the rest of the methods of java.io.Console doesn't use the "get" convention. regards, Rémi ----- Mail original -----
De: "Christoph Langer" <christoph.langer@sap.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Cc: "Baesken, Matthias" <matthias.baesken@sap.com> Envoyé: Vendredi 24 Août 2018 11:33:05 Objet: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
Hi,
please review and give feedback for this augmentation of java.io.Console.
We have users that have the need to query for Width and Height of the console device in Java. In our own JVM implementation we had given them this hook as a custom extension already quite some time ago. We think, however, that it is a worthwhile augmentation of java.io.Console.
Bug: https://bugs.openjdk.java.net/browse/JDK-8209937 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
I'll also open a CSR for this, but I'll wait for some feedback on our proposal first.
Thanks & Best regards Christoph
On 08/24/2018 12:09 PM, Remi Forax wrote:
Hi Christoph, getWidth() and getHeight() should be instance methods and not static methods, providing the weight or the height if there is no console seems weird. Also, they should be named width() and height() given the rest of the methods of java.io.Console doesn't use the "get" convention.
regards, Rémi
They could also return OptionalInt to force user to think about "not-available" situations. Regards, Peter
----- Mail original -----
De: "Christoph Langer" <christoph.langer@sap.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Cc: "Baesken, Matthias" <matthias.baesken@sap.com> Envoyé: Vendredi 24 Août 2018 11:33:05 Objet: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height Hi,
please review and give feedback for this augmentation of java.io.Console.
We have users that have the need to query for Width and Height of the console device in Java. In our own JVM implementation we had given them this hook as a custom extension already quite some time ago. We think, however, that it is a worthwhile augmentation of java.io.Console.
Bug: https://bugs.openjdk.java.net/browse/JDK-8209937 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
I'll also open a CSR for this, but I'll wait for some feedback on our proposal first.
Thanks & Best regards Christoph
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: http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/ Best regards Christoph
-----Original Message----- From: Peter Levart <peter.levart@gmail.com> Sent: Freitag, 24. August 2018 13:06 To: Remi Forax <forax@univ-mlv.fr>; Langer, Christoph <christoph.langer@sap.com> Cc: core-libs-dev <core-libs-dev@openjdk.java.net>; Baesken, Matthias <matthias.baesken@sap.com> Subject: Re: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
On 08/24/2018 12:09 PM, Remi Forax wrote:
Hi Christoph, getWidth() and getHeight() should be instance methods and not static methods, providing the weight or the height if there is no console seems weird. Also, they should be named width() and height() given the rest of the methods of java.io.Console doesn't use the "get" convention.
regards, Rémi
They could also return OptionalInt to force user to think about "not-available" situations.
Regards, Peter
----- Mail original -----
De: "Christoph Langer" <christoph.langer@sap.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Cc: "Baesken, Matthias" <matthias.baesken@sap.com> Envoyé: Vendredi 24 Août 2018 11:33:05 Objet: RFR: 8209937: Enhance java.io.Console - provide methods to query
console width and height
Hi,
please review and give feedback for this augmentation of java.io.Console.
We have users that have the need to query for Width and Height of the console device in Java. In our own JVM implementation we had given them this hook as a custom extension already quite some time ago. We think, however, that it is a worthwhile augmentation of java.io.Console.
Bug: https://bugs.openjdk.java.net/browse/JDK-8209937 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
I'll also open a CSR for this, but I'll wait for some feedback on our proposal first.
Thanks & Best regards Christoph
On 08/24/2018 03:18 PM, 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...
Yes, a good idea. In AWT/Swing such methods are called getSize() or size(): /** * @deprecated As of JDK version 1.1, * replaced by <code>getSize()</code>. */ @Deprecated public Dimension size() { return new Dimension(width, height); } It seems that at some stage, methods like size() have been @Deprecated and replaced with getSize(). Now we're going back from getSize() to size() as the preferred name... I suggest you create a private native method that returns both dimensions (encoded in a jlong for example, with non-existence being -1L) and then do the conversion (to Optional<Console.Dimension>) in a public Java method. It would be much simpler than creating objects in native code... Regards, Peter
Here is a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/
Best regards Christoph
-----Original Message----- From: Peter Levart <peter.levart@gmail.com> Sent: Freitag, 24. August 2018 13:06 To: Remi Forax <forax@univ-mlv.fr>; Langer, Christoph <christoph.langer@sap.com> Cc: core-libs-dev <core-libs-dev@openjdk.java.net>; Baesken, Matthias <matthias.baesken@sap.com> Subject: Re: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
On 08/24/2018 12:09 PM, Remi Forax wrote:
Hi Christoph, getWidth() and getHeight() should be instance methods and not static methods, providing the weight or the height if there is no console seems weird. Also, they should be named width() and height() given the rest of the methods of java.io.Console doesn't use the "get" convention. regards, Rémi They could also return OptionalInt to force user to think about "not-available" situations.
Regards, Peter
----- Mail original -----
De: "Christoph Langer" <christoph.langer@sap.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Cc: "Baesken, Matthias" <matthias.baesken@sap.com> Envoyé: Vendredi 24 Août 2018 11:33:05 Objet: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height Hi,
please review and give feedback for this augmentation of java.io.Console.
We have users that have the need to query for Width and Height of the console device in Java. In our own JVM implementation we had given them this hook as a custom extension already quite some time ago. We think, however, that it is a worthwhile augmentation of java.io.Console.
Bug: https://bugs.openjdk.java.net/browse/JDK-8209937 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
I'll also open a CSR for this, but I'll wait for some feedback on our proposal first.
Thanks & Best regards Christoph
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: http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/ 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 time. -Alan
History: I was always a little disappointed that Console (understandably) didn't support the things you could do with subprocesses in Emacs, like implement shell buffers and otherwise have expect-style conversations with subprocesses. But console dimensions was never on my radar - doesn't mean much in an Emacs shell buffer. Being able to reimplement Emacs in pure Java is of course the ever elusive Holy Grail. Of course, when I run java, it's usually living inside a shell buffer.
Hi Alan, 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? Best regards Christoph
-----Original Message----- From: Alan Bateman <Alan.Bateman@oracle.com> Sent: Montag, 27. August 2018 13:30 To: Langer, Christoph <christoph.langer@sap.com> Cc: core-libs-dev <core-libs-dev@openjdk.java.net>; Baesken, Matthias <matthias.baesken@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: http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/ 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 time.
-Alan
participants (5)
-
Alan Bateman
-
Langer, Christoph
-
Martin Buchholz
-
Peter Levart
-
Remi Forax