Also build and test on Java 17 #1525
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@six42 I don't quite understand why I get the extra newline, but I added some code to deal with the difference. Could probably be done nicer though. So if you have some time.... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update GitHub workflow to also build FitNesse on Java 17 and run all tests
@six42 as you can see I had to update one test case to get the build to pass. It appears that
fitnesse.slim.LoggingOutputStreamdoes not behave the same on Java 17 as it did on earlier versions. An extra newline is added to the execution log for eachprintln()call to either stdin or stout when the communication with the Slim server is not via a socket.I have had issues in the past with this way of communicating between FitNesse and the Slim server (character encoding trouble on an IBM JVM on windows), so in my tests I always just have Slim choose a random free port (by setting the Slim port to
0). Changing the communication protocol to use an actual socket also fixed this test. I couldn't put my finger on why the extra newline is added, but maybe it's an obvious fix for you?I find the name of the class (
LoggingOutputStream) a bit strange also, it's not logging its decorating the input it receives before forwarding it to the nested stream as I understand it. Maybe it would already be much simpler (the newline handling in there) if instead of just forwarding the lines received as text the records would be Base64 encoded (then each record will just always be 1 line I think)?