-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Build and test mergely on JDK 16 (on Travis) #9579
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly LGTM. Just a tiny request, question, and a "let's not do it this way" pushback. 😄
I have a couple of test failures on jdk16... I mentioned it on 3613.
|
is the idea here that if we test on 16, we don't also need to test on 11? |
I'd say that's fine, since we have a community build on 11? |
I don't have a strong feeling either way. (In the community build, I chose to have both 11 and 16 builds, but I chose that mainly because several important upstream maintainers don't support 15 or 16, so the 11 build tests noticeably more stuff. Here in this repo, that doesn't really apply, so 16 only is probably fine. On the other hand, doing 11 too wouldn't be especially costly. 🤷 ) |
On my lunch break, I am PRing removal of use of ThreadGroup in testkit, which is day job adjacent. My other innovative contribution is to pronounce PR as purr. |
68036f4
to
703ea22
Compare
The JDK 16 build went green too: https://travis-ci.com/github/scala/scala/builds/223846952 (I pushed to a scala/scala branch for testing: https://github.com/scala/scala/tree/travis-jdk16) re-review by @dwijnand |
(the github page summarizing the travis build incorrectly says |
@SethTisue whew, when I saw the notification while waiting at child's piano lesson, I wondered if something broke under Thanks for reminding me that I still have to add the ThreadGroup commit to my PR for REPL pretty printing. |
this is a small followup to scala#9579 going warning-free here is a bit tricky, because the method in question is only deprecated on JDK 9+. so on JDK 8 the old code was giving a "@nowarn annotation does not suppress any warnings" warning @lrytz @NthPortal @som-snytt is this best way to handle this?
this is a small followup to scala#9579 going warning-free here is a bit tricky, because the method in question is only deprecated on JDK 9+. so on JDK 8 the old code was giving a "@nowarn annotation does not suppress any warnings" warning @lrytz @NthPortal @som-snytt is this best way to handle this?
No description provided.