Fix Proxy Generation with Final Methods

[SentryMan]

Fixes issue where we would try to generate proxies for classes with final methods.

resolves #895

[rbygrave]

Hmm, so currently when moving the test into blackbox-test-inject, it won't compile as it generates the following method:

  @Override
  protected int next(int arg0) {
    return onceProvider.get().next(arg0);
  }

... which is a protected method, so wanting the use of super here. Hmm.

[SentryMan]

I see

[SentryMan]

Actually I don't see, because when I move it to blackbox it doesn't fail.

... which is a protected method, so wanting the use of super here. Hmm.

to borrow a phrase from my stance on social media, "I don't follow". we don't want the super, we want to call the actual implementation stored in onceProvider

[rbygrave]

So when it's:

  @Bean
  public Random secureRandom() {
    return new SecureRandom();
  }

Then it becomes a registerLazy() [beanReader.proxyLazy()] ... and we get a Random$Lazy generated and that doesn't support the protected method.

 ...
      var factory = builder.get(RandomFactory.class);
      builder.registerLazy(() -> {
      return factory.secureRandom();
      }, Random$Lazy::new);    }

... but with SecureRandom its just a lazy [beanReader.lazy()] ... so no Random$Lazy generated

      var factory = builder.get(RandomFactory.class);
      builder.registerProvider(() -> {
      return factory.secureRandom();
          });

[SentryMan]

well, it appears the bigger problem is situations where the no-arg constructor calls the methods. I'll just an escape hatch to disable proxy generation

[rbygrave]

Ah, but a @Lazy without a proxy ... isn't really lazy in that it be instantiated when it's injected [which is typically early unless it is injected as Provider]? What am I missing?

[SentryMan]

That's exactly right, it's the old behavior if you set that flag to false. In the case of random it doesn't appear that we can cleanly lazy it with a proxy.

[rbygrave]

@SentryMan review the last commit c0ecf8f .... that will generate protected methods that throw UnsupportedOperationException like:

  @Override
  protected int next(int arg0) {
    // @Lazy proxy does not support protected methods, instead use @Lazy(useProxy = false)
    throw new UnsupportedOperationException();
  }

Without this, user will instead get a compilation error which I think will confuse them so I think this might be better?

[SentryMan]

I mean in the first place the generated classes are final so the generated protected methods cannot be accessed

[rbygrave]

the generated protected methods cannot be accessed

Technically they are accessible by classes in the same package as the generated lazy class ... but that does require specific use of the _$Lazy type so the expectation is that isn't something people will do.

So yeah, if you are happy with that last commit we can look to merge this etc.

[SentryMan]

Lgtm

[SentryMan]

Actually one sec

[SentryMan]

okay good with this