Re: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
To the core-libs ... On 8/24/18, 9:56 AM, Xueming Shen wrote:
Hi Langer,
I would suggest to add explicit wording to emphasize the "size" means the rows and columns in characters, not the pixels.
It appears attractive to have a Console.Dimension to abstract the size and make it an "atomic" access but I'm not sure if it's really worth the cost to have an extra class merely for this purpose. getWidth/Height might be just good enough for most possible use scenario for Console class. Maybe we can add a getSize() when we have a better abstract/choice later, for example, "tuples/pair" ? :-)
A little background, the design decision of the Console class back then was to avoid those platform dependent term curses related stuff, so those size, cursor related functionality were purposely removed from the final API and implementation ...
Thanks, Sherman
On 8/24/18, 6:41 AM, Peter Levart wrote:
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
Hi, This feels like a pretty slippery slope; not enough for real terminal emulation; what kind of terminal is it?, etc. Not enough for jshell/nashorn, which imported a whole package to support command line editing. (jline - module jdk.internal.le/ed) Regardless, keep it simple! There are very few terminals in the cloud. On 8/24/18 12:58 PM, Xueming Shen wrote:
To the core-libs ...
On 8/24/18, 9:56 AM, Xueming Shen wrote:
Hi Langer,
I would suggest to add explicit wording to emphasize the "size" means the rows and columns in characters, not the pixels.
It appears attractive to have a Console.Dimension to abstract the size and make it an "atomic" access but I'm not sure if it's really worth the cost to have an extra class merely for this purpose. getWidth/Height might be just good enough for most possible use scenario for Console class. Maybe we can add a getSize() when we have a better abstract/choice later, for example, "tuples/pair" ? :-) +1
A little background, the design decision of the Console class back then was to avoid those platform dependent term curses related stuff, so those size, cursor related functionality were purposely removed from the final API and implementation ...
Thanks, Sherman
On 8/24/18, 6:41 AM, Peter Levart wrote:
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
participants (2)
-
Roger Riggs
-
Xueming Shen