jspecify icon indicating copy to clipboard operation
jspecify copied to clipboard

The build vs. JDK versions

Open kevinb9n opened this issue 3 years ago • 2 comments

I don't understand build stuff, but I ?think? that currently:

  • Most gradle commands respect the "environmental" JDK
  • The main compile uses -source 8 -target 8 to make sure the JAR is 8-compatible
  • Our github actions use this to test out several different JDKs

But isn't the only thing that we really need to splay out to multiple JDKs for tests? More to the point: since we will only be releasing one artifact, shouldn't these should all test against the exact same single jar -- the one we will actually publish?

So I'm wondering if for purposes of compilation we can/should hardcode a JDK version? And if we do the same thing for the javadoc generation (setting it to say 17) it would fix the current issue that it's failing on JDK 11.

As for running tests though, I suppose it's okay to keep working as it has been? I don't know what the tradeoffs would be of moving to one distinct more-hermetic gradle target for each.

kevinb9n avatar Aug 22 '22 23:08 kevinb9n

Yes!

I meant to comment on the original PR but it landed before I had a chance. I wrote about this a bit here. Gradle makes this super easy. Set your toolchain to 18 (19 in a few weeks!) and create a test task for each JDK in your supported range.

JakeWharton avatar Aug 22 '22 23:08 JakeWharton

Whoa thanks, that's perfectly helpful!

kevinb9n avatar Aug 22 '22 23:08 kevinb9n