Target java17

[pditommaso]

This set Java 17 as target bytecode generation and lang compatibility.

TLDR; so far mock created by Spock used cglib, which is not maintained anymore and does not support Java 17. Bytebuddy should replace it, but some tests fail.

https://spockframework.org/spock/docs/2.0-M4/faq.html

[netlify]

✅ Deploy Preview for nextflow-docs-staging ready!

Name	Link
🔨 Latest commit	4cf67e4
🔍 Latest deploy log	https://app.netlify.com/sites/nextflow-docs-staging/deploys/66c39d369797250007e4c2fc
😎 Deploy Preview	https://deploy-preview-5045--nextflow-docs-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[pditommaso]

@bentsherman when you have some chance, it would be nice to fix the failing tests so we can move to Java 17 as target bytecode

[bentsherman]

So this will drop support for Java 11?

[pditommaso]

Yes, it may be needed to drop support for Java 11 since it's becoming more and more complicated to make coexisting different projects with Java 11 as baseline

[pditommaso]

Not needed in the short term. Closing for now

[bentsherman]

The factor connecting all of the failing tests is that they are mocking or spying RepositoryProvider or a subclass of it. The GithubRepositoryProviderTest is the only test that mocks a subclass, all of the other provider subclasses do not.

• Adding a default constructor didn't fix it (I think these are not needed anyway thanks to objenesis).
• Making RepositoryProvider concrete instead of abstract didn't fix it
• Moving TagInfo and BranchInfo out of RepositoryProvider didn't fix it (read somewhere that bytebuddy has issues mocking inner classes)

[pditommaso]

@bentsherman do you have a concrete need for Java 17? I guess there are still people running on Java 11

[bentsherman]

The main feature I'm using is this pattern matching syntax:

if( node instanceof Expression exp ) {
  // ...
}

Whereas with Java 11 I would have to do:

if( node instanceof Expression ) {
  var exp = (Expression) node;
  // ...
}

I use this a lot in the parsing and AST code, so it does make the code more concise. But I can go back to the old way if lots of people still rely on Java 11. I figured it should be pretty easy to upgrade to Java 17 these days, I don't know how many people would actually be stuck with 11

[pditommaso]

Understand. Are you sure that this requires Java 17 bytecode generation and not Java 17 lang compatibility?

[bentsherman]

I did try that:

java {
  sourceCompatibility = JavaVersion.VERSION_17
  targetCompatibility = JavaVersion.VERSION_11
}

But I was surprised to find it wasn't allowed:

Execution failed for task ':language-server:compileJava'.
> warning: source release 17 requires target release 17

[bentsherman]

But maybe there is some other way to do it that I don't know about? I would expect Java to still be able to generate Java 11 bytecode with such a simple change, but maybe there are other deeper changes that make it impossible

[bentsherman]

Java 11 seems to be in a similar EOL status as Java 8, at least for Oracle Java: https://endoflife.date/oracle-jdk

So I think it would be safe to require Java >=17. Users always have the previous versions of Nextflow

Maybe it would be helpful to look up the compatibility matrices of other Java projects of similar size to see what they're doing

[pditommaso]

I agree this is a nice to have. I'd like just postpone merging this to post 24.10.x to not fragment too much Java requirement for this year stable releases.

[bentsherman]

Fine by me. I was actually going to suggest waiting until 25.04 . We can merge the new config parser then too. That will give me more time to stabilize some things

[bentsherman]

• or an edge release after 24.10