Bootstrapper's intitialize method should be named initialize

[cprayer]

This PR fixes a minor typo in Bootstrapper class.

[wilkinsona]

Thanks for spotting this and opening a PR, @cprayer. We'll have to refine things a bit to deprecate the intitialize method and add the initialize method alongside it. Hopefully we can use a default method so that it's not a breaking change. We can do that as part of merging.

[cprayer]

@wilkinsona Thank you for your review. I have changed the code as you said. How about this?

[philwebb]

Oh dear, that's an embarrassing typo from me in the original 🤦 . Thanks for spotting it @cprayer.

[spencergibb]

This doesn't handle the case where Bootstrapper implementers that has been released and only implemented intitialize (the misspelling) will continue to work. As it is coded, it will fail. I think that SpringApplication needs to continue to call the deprecated method until it is removed and the deprecated method needs to default to calling the new one.

[wilkinsona]

Thanks for looking, @spencergibb.

I think that SpringApplication needs to continue to call the deprecated method until it is removed and the deprecated method needs to default to calling the new one.

I think it would be better if we could get into a situation where implementors don't have to have any code in the deprecated method.

Would it work if we make initialize (correct) a default method that calls intitialize (typo)? SpringApplication can then call initialize(correct) and the default method will delegate this to any existing implementation's intitialize (typo). When they upgrade and notice the deprecation warning, they can move the code from intitialize (typo) into initialize (correct) and leave intitialize (typo) empty as it'll never be called.

[philwebb]

I wonder if we're going to have a binary compatibility issue if people are using the Bootstrapper as a lambda?

[philwebb]

I'm guessing we might need to put the smarts in SpringApplication. We should probably call both methods and also deal with NoSuchMethodError.

[spencergibb]

I'm fine either way, just as long as existing implementors don't get broken because they may use the deprecated method or have used a lambda.

[wilkinsona]

I wonder if we're going to have a binary compatibility issue if people are using the Bootstrapper as a lambda?

I don't believe we will. Bootstrapper is still considered to be a functional interface when the default method is added as it still has a single abstract method.

We should probably call both methods and also deal with NoSuchMethodError.

That feels risky to me as, depending on how someone has implemented their Bootstrapper, it may result in initialization being performed twice.

I think we can do this with a default method as I outlined above.

[cprayer]

@wilkinsona
I have wrote a simple code to make sure binary compatibility issue.
It is using openjdk 1.8.0_252, intellij idea community 2021.3.1, and gradle.

First version (https://github.com/cprayer/binary-compatibility-test-first-version)

Main.java

package org.example;

public class Main {
    public static void main(String[] args) {
        Typo typo = () -> "hello world";
        Test test = new Test();
        test.test(typo);
        System.out.println(typo.typpo());
    }
}

Test.java

package org.example;

public class Test {
    public void test(Typo typo) {
        System.out.println(typo.typpo());
    }
}

Typo.java

package org.example;

public interface Typo {
    String typpo();
}

First version result

shasum -a 256 first/build/classes/java/main/org/example/Main.class
11425f57f59d52ef0076638eb71d7478d6be2ab4a9e2b9ff5d1f89872022a7d4  first/build/classes/java/main/org/example/Main.class

Second version(https://github.com/cprayer/binary-compatibility-test-second-version)

Main.java

package org.example;

public class Main {
    public static void main(String[] args) {
        Typo typo = () -> "hello world";
        Test test = new Test();
        test.test(typo);
        System.out.println(typo.typpo());
    }
}

Test.java

package org.example;

public class Test {
    public void test(Typo typo) {
        System.out.println(typo.typo());
    }
}

Typo.java

package org.example;

public interface Typo {
    String typpo();

    default String typo() {
        return typpo();
    }
}

Second version result

shasum -a 256 second/build/classes/java/main/org/example/Main.class
11425f57f59d52ef0076638eb71d7478d6be2ab4a9e2b9ff5d1f89872022a7d4  second/build/classes/java/main/org/example/Main.class

I think it doesn't have binary compatibility issue.

[wilkinsona]

That's really helpful, @cprayer. Thank you. In addition to that check, I've built 2.4.4-SNAPSHOT locally and used Spring Cloud Context 3.0.1 with it. org.springframework.cloud.bootstrap.TextEncryptorConfigBootstrapper.intitialize(BootstrapRegistry) is called as expected via the initialize default method.

[spencergibb]

Thanks for checking on that @wilkinsona.

[wilkinsona]

@cprayer Thanks very much for making your first contribution to Spring Boot.