SpringBoot Bootstrapper's intitialize method should be named initialize

This PR fixes a minor typo in Bootstrapper class.

Comment From: 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.

Comment From: cprayer

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

Comment From: philwebb

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

Comment From: 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.

Comment From: 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.

Comment From: philwebb

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

Comment From: philwebb

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

Comment From: 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.

Comment From: 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.

Comment From: 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.

Comment From: 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.

Comment From: spencergibb

Thanks for checking on that @wilkinsona.

Comment From: wilkinsona

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