Output from my own plugin test, built with Gradle 8.6:

The task 'bootStartScripts' (org.gradle.jvm.application.tasks.CreateStartScripts) is not a subclass of the given type (org.gradle.api.tasks.application.CreateStartScripts)

Shouldn't custom tasks prefer the API versions of tasks? org.gradle.api.tasks.application.CreateStartScripts extends org.gradle.jvm.application.tasks.CreateStartScripts anyway.

Comment From: philwebb

@cpuzicha Do you have a way for us to replicate the "The task 'bootStartScripts' (org.gradle.jvm.application.tasks.CreateStartScripts) is not a subclass of the given type (org.gradle.api.tasks.application.CreateStartScripts)" error?

I'm not sure we've seen it in our own tests.

Comment From: cpuzicha

File: build.gradle.kts

plugins {
    id("java")
    id("application")
    id("org.springframework.boot") version "3.2.2"
}

group = "org.example"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

tasks.withType(CreateStartScripts::class).forEach {
    logger.lifecycle("Found start script task: ${it.name}")
}

tasks.named("bootStartScripts").get().let {
    logger.lifecycle("${it.name} has class ${it::class.qualifiedName}")
}

tasks.named("bootStartScripts", CreateStartScripts::class) {
    //fails
}

Comment From: mhalbritter

sb-39584.zip

Here's one which we can unzip and use.

Comment From: mhalbritter

If I change in org.springframework.boot.gradle.plugin.ApplicationPluginAction

import org.gradle.jvm.application.tasks.CreateStartScripts;

to

import org.gradle.api.tasks.application.CreateStartScripts;

our build still works.

However I lack the Gradle knowledge to determine if this is the right thing to do.

Comment From: wilkinsona

It could be argued that this is user error as it's making an assumption about the type of the bootStartScripts task that doesn't hold true. This should work:

tasks.named("bootStartScripts", org.gradle.jvm.application.tasks.CreateStartScripts::class) {
    // works?
}

That said, I don't think there's any good reason for us to be using org.gradle.jvm.application.tasks.CreateStartScripts rather than org.gradle.api.tasks.application.CreateStartScripts. I suspect it's just an accident of auto-completion when I worked on https://github.com/spring-projects/spring-boot/issues/20759 and perhaps a hangover from https://github.com/spring-projects/spring-boot/issues/2622.

Given that Gradle implicitly imports the org.gradle.api.tasks.* classes into your build script, there is a good reason for us to be using org.gradle.api.tasks.application.CreateStartScripts. Furthermore, org.gradle.api.tasks.application.CreateStartScripts is a subclass of org.gradle.jvm.application.tasks.CreateStartScripts. I think it's very unlikely that anyone has written a build the relies upon bootStartScripts specifically being an instance of org.gradle.jvm.application.tasks.CreateStartScripts so I think we can safely change to org.gradle.api.tasks.application.CreateStartScripts as a bug fix in 3.1.x.

Comment From: cpuzicha

Even if they did, the .api class extends the .jvm class

Comment From: cpuzicha

Any reason this is added to 3.1.x but not to 3.2.x and most importantly the main branch?

Comment From: wilkinsona

We fix in the oldest affected branch and then merge forwards. The fix will land in 3.1.x and then be merged forwards into 3.2.x and then main.