You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* 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 <[email protected]>
Co-authored-by: Roman Elizarov <[email protected]>
Copy file name to clipboardExpand all lines: README.md
+2-1
Original file line number
Diff line number
Diff line change
@@ -203,8 +203,9 @@ to Gradle (in Preferences -> Build, Execution, Deployment -> Build Tools -> Grad
203
203
204
204
### Requirements
205
205
206
-
* JDK >= 1.8 referred to by the `JAVA_HOME` environment variable. JDK must include JavaFX.
206
+
* JDK >= 11 referred to by the `JAVA_HOME` environment variable.
207
207
* JDK 1.6 referred to by the `JDK_16` environment variable. It is okay to have `JDK_16` pointing to `JAVA_HOME` for external contributions.
208
+
* JDK 1.8 referred to by the `JDK_18` environment variable. Only used by nightly stress-tests. It is okay to have `JDK_16` pointing to `JAVA_HOME` for external contributions.
0 commit comments