Build project using JDK 11 #1733
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
dkhalanskyjb
force-pushed
the
jdk-11
branch
5 times, most recently
from
cec36f0
to
c37b5f9
Compare
elizarov
commented
Jan 30, 2020
elizarov
force-pushed
the
jdk-11
branch
2 times, most recently
from
cb57f3b
to
8c1addf
Compare
|
Passes all tests on JDK11 & also tested to pass stress tests. Ready for merge! |
* Up the Robolectric version to support JDK11. According to robolectric/robolectric#4085, by 4.0.2 it should support JDK11. Tests do pass after setting the version to 4.0.2, but they fail for every version released after that up to 4.3.1. It is unclear what causes this. I commit this to check how it works on the build agents, as some comments in the issue imply that on MacOS thes version, too, does not work with JDK11. * Fix fully qualified names in stacktraces in tests: - With move to JDK11, the `park` method changed its fully qualified name. * Add new sanitazing to verification of stacktraces: - Now stacktraces have additional substrings, separated by a slash: java-base/java.util.lang - They are stripped away. - Also, the placement of tabs has changed, and so the tabs are also completely removed. * Refactor `verifyStackTrace` - It used to wrap the only loop where something happened in two other loops that did nothing. Now, only the innermost loop is left. * Use a separate JavaFx dependency. * Add javafx dependency to the Swing integration * Improve error handling for JavaFX initialization - Now, the JavaFX initialization may fail with an exception in case something went wrong. - The driver for this change was that the initialization started hanging in headless environments with transition to JDK 11. - Before, the initialization logic had a flaw. If a call to one API failed, another API would be attempted. However, this approach is problematic: if the first call failed with an exception for some reason, it would leave JavaFX in a broken state where a flag would imply that the system is being initialized. Subsequent calls would then proceed to wait forever for the initialization to complete. - Now, exceptions are checked more carefully, ensuring that we only fall back to the internal API in case the public one is unavailable and not failed for some valid reason. This differentiation also allows to more boldly rethrow exceptions upwards, being more or less confident that these are relevant to the user. * Additionally test JavaFX integration with JDK8 Co-authored-by: Dmitry Khalanskiy <dmitry.khalanskiy@jetbrains.com> Co-authored-by: Roman Elizarov <elizarov@gmail.com>
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.
No description provided.