-
Task
-
Resolution: Fixed
-
P4
-
None
-
b21
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8327116 | 21.0.4-oracle | Vanitha B P | P4 | Resolved | Fixed | b01 |
JDK-8327556 | 21.0.4 | Goetz Lindenmaier | P4 | Resolved | Fixed | b01 |
1. The HelloImpl and HelloClient classes aren't adding much value and can pretty much be deleted if the object is exported with something like:
Hello stub = (Hello) UnicastRemoteObject.exportObject(new HelloImpl(), port, csf, ssf);
or similar.
2. The ClientFactory and ServerFactory classes aren't adding much value. They override the create methods and print a message, but otherwise don't do anything beyond what's done in their respective superclasses.
3. The exception handling is now fairly simple, but one still needs to read through the code to figure out what is actually being tested. The expectedException boolean also makes things a little harder to read since it can invert the logic. I observe that the various test frameworks (such as Test-NG or JUnit) have APIs for this such as assertThrows or expectThrows which return the caught exception, allowing additional assertions to be made over it, and failing the test if the expected exception type isn't thrown. I think this would improve the test cases where an exception is expected, but it might not be worth the effort of converting to one of the frameworks.
Hello stub = (Hello) UnicastRemoteObject.exportObject(new HelloImpl(), port, csf, ssf);
or similar.
2. The ClientFactory and ServerFactory classes aren't adding much value. They override the create methods and print a message, but otherwise don't do anything beyond what's done in their respective superclasses.
3. The exception handling is now fairly simple, but one still needs to read through the code to figure out what is actually being tested. The expectedException boolean also makes things a little harder to read since it can invert the logic. I observe that the various test frameworks (such as Test-NG or JUnit) have APIs for this such as assertThrows or expectThrows which return the caught exception, allowing additional assertions to be made over it, and failing the test if the expected exception type isn't thrown. I think this would improve the test cases where an exception is expected, but it might not be worth the effort of converting to one of the frameworks.
- backported by
-
JDK-8327116 Refactor/cleanup open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java
- Resolved
-
JDK-8327556 Refactor/cleanup open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java
- Resolved
- relates to
-
JDK-8298939 Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test
- Resolved
- links to
-
Commit openjdk/jdk21u-dev/e7994c1d
-
Commit openjdk/jdk/704c6ea1
-
Review openjdk/jdk21u-dev/323
-
Review openjdk/jdk/14932
(2 links to)