Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop GraalVM 19.2.1 support and deprecate enableJni option #6792

Merged

Conversation

gwenneg
Copy link
Member

@gwenneg gwenneg commented Jan 25, 2020

Fixes #6709 and #6101

Copy link
Member

@gsmet gsmet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks very good. I added one question inline and I have another one: I wonder if adding the SunEC library is still necessary to get SSL working? But that's material for another PR if it ends up being useless.

(Marking as Request changes so that we can discuss things before it being merged)

} else if (prop.getKey().equals("quarkus.jni.enable") && prop.getValue().equals("false")) {
log.warn("Your application is setting the deprecated 'quarkus.jni.enable' configuration key to false."
+ " Please consider removing this configuration key as it is ignored (JNI is always enabled) and it"
+ " will be removed in a future Quarkus version.");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be sure: have you tested that you don't have several identical messages when setting quarkus.jni.enable=false?

Copy link
Member Author

@gwenneg gwenneg Jan 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it with #6306 but I'll restest it again with this PR just to be sure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless I missed something, this warning is never displayed with the current Quarkus codebase. I suppose this is an old property that is no longer used by the core extensions, but it can still be used by 3rd parties extensions.

On the other hand, the warning from JniProcessor is displayed when quarkus.jni.enable is set to false.

I don't think we should worry about duplicate warnings here since it's very unlikely to happen.

@gsmet gsmet added this to the 1.3.0 milestone Jan 26, 2020
Copy link
Member Author

@gwenneg gwenneg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Including the SunEC lib should not be required anymore, but I agree this should be treated separately.

I need to test this PR with JDK 11 in native mode (btw, thanks @geoand for your indications about how to do it with GitHub actions!), I'll promote the PR when I'm done with the tests.

@geoand
Copy link
Contributor

geoand commented Jan 26, 2020

Looking forward to it! Thanks @gwenneg!

@gwenneg
Copy link
Member Author

gwenneg commented Jan 26, 2020

For the record, the GitHub action got triggered with these two changes in native-cron-build.yml:

on:
  pull_request:
    branches:
      - master

and

jobs:
  build:
[...]
    steps:
[...]
      - name: Checkout Quarkus
        uses: actions/checkout@v2
        with:
          repository: gwenneg/quarkus
          ref: issue-6709-drop-graalvm-19.2.1-compatibility

@gwenneg
Copy link
Member Author

gwenneg commented Jan 26, 2020

It's really great to have this GH action available, I don't have to run JDK 11 native tests locally for an entire night anymore 😆

@gwenneg gwenneg force-pushed the issue-6709-drop-graalvm-19.2.1-compatibility branch from a78b6f6 to 493d1aa Compare January 27, 2020 00:52
@gwenneg
Copy link
Member Author

gwenneg commented Jan 27, 2020

@geoand It seems the JDK 11 native tests got canceled because of their duration. Is there a way to configure the GitHub action and prevent this? I tried something in c8d7090 but it didn't do anything.

@geoand
Copy link
Contributor

geoand commented Jan 27, 2020

I think 6 hours is the max. Did you try executing "only" the integration tests and nothing else like the current cron job does?

@gwenneg
Copy link
Member Author

gwenneg commented Jan 27, 2020

The native tests got canceled after 3h 34m 19s at step 47/75 so it needs to run roughly for another couple hours (JDK 11 tests take so much time compared with the JDK 8 version...). I didn't change anything apart from the branch and job launch condition so it should behave like the current cron job.

@gwenneg
Copy link
Member Author

gwenneg commented Jan 27, 2020

It seems the usual cron job runs these tests in approximately 5 hours so mine shouldn't be interrupted like that. Maybe there's an interruption cause unrelated with the tests duration.

@gsmet
Copy link
Member

gsmet commented Jan 27, 2020

If you have one of the tests of the matrix failing, it auto-cancels the others AFAICS.

@gsmet
Copy link
Member

gsmet commented Jan 27, 2020

@gwenneg
Copy link
Member Author

gwenneg commented Jan 27, 2020

Oh then the cancelation could be caused by the failure in the Report step of the JDK 8 action! It happened at the same time.

@gsmet
Copy link
Member

gsmet commented Jan 27, 2020

BTW, there's little change the report part can work in a PR as you're not supposed to have the token.

And things shouldn't be reported to the same issues anyway. So I would drop that part.

@geoand
Copy link
Contributor

geoand commented Jan 27, 2020

Like @gsmet mentioned, please change the reporting for your testing so we don't get mixed information in the issue :)

@gwenneg gwenneg force-pushed the issue-6709-drop-graalvm-19.2.1-compatibility branch from 8df9d6b to 4fe96c9 Compare January 27, 2020 17:30
@gwenneg
Copy link
Member Author

gwenneg commented Jan 28, 2020

The native integration tests run finally ended successfully for both GH actions. I'll check the absence of duplicate warnings about quarkus.jni.enable=false tonight.

@geoand
Copy link
Contributor

geoand commented Jan 28, 2020

Excellent news!

@gastaldi
Copy link
Contributor

Looks like this Draft PR is ready to be promoted to a real PR? :)

@geoand
Copy link
Contributor

geoand commented Jan 28, 2020

As long as the changes to the github actions are reverted :)

@gwenneg
Copy link
Member Author

gwenneg commented Jan 28, 2020

@gastaldi It’s not ready to be promoted yet, I need to check for duplicate warnings locally first. And I will revert the actions changes of course.

@gwenneg gwenneg force-pushed the issue-6709-drop-graalvm-19.2.1-compatibility branch from 925005d to 4c193ae Compare January 28, 2020 20:39
@gwenneg
Copy link
Member Author

gwenneg commented Jan 28, 2020

The JDK 11 native build and tests all passed successfully (see details here), the GitHub actions changes were removed and I'm done looking for duplicate warnings, so I'm promoting this PR.

@gwenneg gwenneg marked this pull request as ready for review January 28, 2020 22:45
@geoand geoand requested a review from gsmet January 29, 2020 08:49
Copy link
Contributor

@gastaldi gastaldi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. I'll let @gsmet review and decide when to land this PR

@gsmet gsmet merged commit b61f69d into quarkusio:master Jan 29, 2020
@gsmet
Copy link
Member

gsmet commented Jan 29, 2020

Merged, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Drop the GraalVM 19.2.1 compatibility
4 participants