-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8332161: Test restoring echo in the Console implementation (java.base) #19315
Conversation
Co-authored-by: ExE Boss <3889017+ExE-Boss@users.noreply.github.com>
👋 Welcome back naoto! A progress list of the required criteria for merging this PR into |
@naotoj This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 83 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
The parent pull request that this pull request depends on has now been integrated and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout JDK-8332161-restoreEcho-Test
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push |
@naotoj this pull request can not be integrated into git checkout JDK-8332161-restoreEcho-Test
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
|
I might be mistaken, but this looks like a very well written unit test, which tests that an implementation flag retains its initial value. This does not look like an end-to-end test, which we usually write. I wonder if we can use The difference between the above approach and the test that this PR has proposed is that with the above approach we won't rely on an implementation detail, whose relevance to an objectively observed state is non-obvious or unknown. Instead, we'll use an OS utility, which makes for a relevant, straightforward, and maintainable test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like a better, end-to-end test. Thank you for your perseverance. Below are some comments.
var jdkDir = System.getProperty("test.jdk"); | ||
OutputAnalyzer output = ProcessTools.executeProcess( | ||
"expect", | ||
"-n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does -n
do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is for not reading the user's expect settings (~/.expect.rc
if any)
testSrc + "/restoreEcho.exp", | ||
initialEcho, | ||
jdkDir + "/bin/java", | ||
"--add-opens=java.base/jdk.internal.io=ALL-UNNAMED", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't seem to need --add-opens
.
jdkDir + "/bin/java", | ||
"--add-opens=java.base/jdk.internal.io=ALL-UNNAMED", | ||
"-Djdk.console=java.base", | ||
"-classpath", testClasses, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider this. If we remove -classpath
(and var testClasses
), not only will nothing break, but we'll be also able to use JUnit assertions and assumptions in main
instead of manual check-then-throw. This will work because the expect-process will inherit the environment, which captures CLASSPATH
( see https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/ProcessBuilder.html#start() ).
Again, the above is just something to consider. For all I know, you might've considered it already and rejected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't considered that. Removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turned out that removing the classpath ends up not finding the test class:
Error: Could not find or load main class RestoreEchoTest
Caused by: java.lang.ClassNotFoundException: RestoreEchoTest
];
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turned out that removing the classpath ends up not finding the test class:
Error: Could not find or load main class RestoreEchoTest Caused by: java.lang.ClassNotFoundException: RestoreEchoTest ];
Hm... this is surprising. On my machine, testSrc
expands to the JTwork/classes/0/java/io/Console/RestoreEchoTest.d
directory, which is included in CLASSPATH
and which contains RestoreEchoTest.class
.
if (eval != 0) { | ||
throw new RuntimeException("Test failed. Exit value from 'expect' command: " + eval); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could've been assertEquals(0, output.getExitValue())
.
|
||
// testing readLine() | ||
String input = con.readLine("prompt: "); | ||
con.printf("input is %s\n", input); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that this test is only run on Linux and macOS, and yet %n
would be better than \n
. It's one of those cases where it's simpler to use a general solution than to use a less general one and explain why it still does the job.
|
||
// testing readPassword() | ||
input = String.valueOf(con.readPassword("password prompt: ")); | ||
con.printf("password is %s\n", input); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto on %n
.
# readPassword() - input is not displayed | ||
test "$rpprompt" "$rpinput" "-echo" "$rpexpected" | ||
# See if the initialEcho is restored with `stty -a` | ||
expect " $initialEcho " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you leave out those whitespace characters inside the quotes and $initialEcho
expands to -echo
, it will be treated as an option to expect
, right? If so, consider this instead:
expect -- $initialEcho
But more importantly: could a test match echo
in -echo
and therefore falsely pass?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spaces before/after $initialEcho
are exactly to distinguish "echo" from "-echo", otherwise the test falsely succeeds as you pointed out. Although the test works as expected as it is, adding --
would be safer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's clever. However, we now depend on (-)echo
being in the middle of the line, no? If stty -a
format (IEEE Std 1003.2) allows (-)echo
to appear in an arbitrary position of a line, our check won't work.
If (-)echo
appears in a leading position, it might be preceded by a TAB (similarly to -echoprt
below). If (-)echo
appears in a trailing position, it is followed by newline (similarly to echoctl
below).
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl$
^I-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo$
^I-extproc$
But I guess, it's good enough and certainly much better than the initially proposed unit test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for having done it, Naoto.
/integrate |
Going to push as commit 25ad862.
Your commit was automatically rebased without conflicts. |
This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19315/head:pull/19315
$ git checkout pull/19315
Update a local copy of the PR:
$ git checkout pull/19315
$ git pull https://git.openjdk.org/jdk.git pull/19315/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 19315
View PR using the GUI difftool:
$ git pr show -t 19315
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19315.diff
Webrev
Link to Webrev Comment