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.lev...@gmail.com>
Sent: Freitag, 24. August 2018 13:06
To: Remi Forax <fo...@univ-mlv.fr>; Langer, Christoph
<christoph.lan...@sap.com>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>; Baesken, Matthias
<matthias.baes...@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.lan...@sap.com>
À: "core-libs-dev" <core-libs-dev@openjdk.java.net>
Cc: "Baesken, Matthias" <matthias.baes...@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
