This repository has been archived by the owner on Dec 3, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
Support Java 11 #204
Comments
carltonwhitehead
added a commit
to coner-tech/coner-worker
that referenced
this issue
Feb 6, 2018
Not going to bother with supporting Java 9 since it is already EOL and 10 is not far behind. Changing ticket to support Java 11, since it is an LTS version supported through 2023 according to http://www.oracle.com/technetwork/java/eol-135779.html |
carltonwhitehead
added a commit
to coner-tech/coner-worker
that referenced
this issue
Aug 6, 2018
#17 (#21) * SNAPSHOT Coner Core service process management * Split the integration test off from ConerCoreProcessTest * Disabling Java 9 temporarily until Coner Core service is updated See coner-tech/coner-core#204 * Quality of life improvements for running integration tests - Integration tests moved to separate source dir - More flexible and robust coner core service version resolution - Comment warning of ConerCoreProcessIT's dependencies * Revise the warning comment in ConerCoreProcessIT * Move the warning to the KDoc * Convert managed process startup to async * Convert managed process teardown to async * Add integration tests to jacoco * Improve integration test precondition checks, refactor Automatic dependency checks with helpful error messages are better than code comments with an all caps warning message. * Reorganize package and test structure Previously, UI view, controller, and model classes were gathered in files grouped by the screen they represent, but were in a package `page`. Test Page Object Model classes were being placed alongside them inside the test, leading to test files growing excessively with mixed concerns. Now, UI view, controller, and model classes for particular screens are gathered in the `screen` package in one file per screen. Test Page Object Model classes will be placed in the `page` package` with one file per page. No functional changes. * SNAPSHOT Easy mode * SNAPSHOT Easy mode attempts to start process and connect * Upgrade tornadofx * SNAPSHOT Easy mode can start a core service process Still need to cleanup the success and failure handling - Save connection preferences as Method.EASY_MODE - Consider Method refactor to sealed class with type property - Clean up host and port references * Restructure screen package for establish connection * SNAPSHOT Revise connection preferences storage * SNAPSHOT Revise connection preferences storage again * SNAPSHOT validate coner core service jar file exists * SNAPSHOT refactor config preferences i/o * SNAPSHOT refactor config preferences i/o again simpler now, with added lightness * SNAPSHOT refactor config preferences i/o a third time * Reduce duplication of default values, eliminate some hard coded strings * Read the model's item * Use extension functions to save and load the connection prefs from config * SNAPSHOT: eliminate UI duplication of model default values TODO: fix the port number fields empty after input filter sees a comma * Fix port number formatting * SNAPSHOT: Update the CustomConnectionViewTest following refactors * Fix the Coner Core Service Connection Details view tests * Re-add test dependency on monocle * Assert of the FX app thread * Specify testfx-core dependency * Use a headless linux environment, update oracle java * Reverting testfx to 4.0.12-alpha See TestFX/TestFX#568 * Raise the testfx setup timeout on travis * Initial UI tests for the Easy Mode connection screen * Add some easy mode tests * Test when easy mode config file selected doesn't exist * Slightly faster easy mode tests * Test the Establish Connection page * Establish Connection Page can traverse children * Clean up page objects, use dependency injection * Don't defer the MainController init * Guard exiting while Coner Core service process is running * Refactor the close alert dialog * Use safety orange on default buttons * Depend on coner-core 0.1.24, refactor integration test environment setup * Use the snapshot build of coner core * Upgrade dependencies * POM's coner-core.version (and eventually others) property available at runtime * Upgrade Kotlin version * SNAPSHOT: resolve coner worker jar with eclipse aether * SNAPSHOT: resolve coner worker jar with eclipse aether * SNAPSHOT: resolve coner worker jar with eclipse aether * SNAPSHOT: resolve coner worker jar with eclipse aether * SNAPSHOT: resolve coner worker jar with eclipse aether * Refactor Easy Mode set up and tear down under a single controller * Refactor the connection preference signaling * A tiny bit of detail to the UI about Easy Mode start progress steps * Use proper method for marking default button in custom connection view * Tinker with the color scheme * Raise the primary stage size * Restyle the header * Adjust the drop shadow * Shrink the stage * Minor clean up in the Easy Mode screen * Test the Easy Mode connection UI * Test EasyModeController * Use the JVM property java.home for starting the Coner Core service * Decorate the establish connection view * Unpack coner core config file from resource * Test the ConerCoreProcessController * Expand unit tests for ConerCoreProcessController * Use latest coner core release version * Use kotlin incremental compilation * Relax the ci profile activation * Revise the ci profile activation for travis * Refactor and test the MavenController * Upgrade kotlin version * Fix deprecated dependency * Add slf4j simple logger
I installed an Oracle OpenJDK 11 build locally and tried to run the tests. Looks like the use of Lombok in some of the models is a blocker. Very minor usage of the I'm currently seeing this as a great excuse to rewrite those few models and the locations where they're called in Kotlin in order to remove the Lombok dependency. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Building on Java 9 currently produces a MapStruct error. MapStruct released a new version adding Java 9 compatibility in October 2017, and we are on an earlier version.
Dropwizard has a release candidate mentioning Java 9 support.
There could be a host of other issues waiting for us as well after the above things are taken care of. It would be good to start documenting those here. This ticket may be closed when this project can build, pass its tests, and run on Java 9 with no apparent regressions.
This would be a good task for a new contributor to start, and it would be a big help to the project.
The text was updated successfully, but these errors were encountered: