unfortunately protected val kotlinBinder: KotlinBinder by lazy { does not always work fine and can cache wrong binder. As result guice can't find some dependencies even these are declared.

please take a look test that confirm this issue here https://github.com/ashirman/kotlin_guice_bind_error_test

it is fairly easy to cache "wrong" binder for Kotlin module. Eg val elements = Elements.getElements(modules). it uses RecordingBinder which is cached by Kotlin module after first usage.

the only solution that I was able to find saving backward compatibility is to delete by lazy { for kotlinBinder: KotlinBinder.

Since everything is final by default in kotlin, guice's interceptors don't immediately work, and in fact silently fail. This is not hard to google a solution to, assuming you have tests around the caching; however, the kotlin wrapper should either detect this and raise an error, or (ideally) provide a solution (perhaps an open delegating proxy) that allows aop to work.

Hello,

Just to let you know that the released version on maven central (the one being pulled by gradle) is still pointing its kotlin dependencies to org.jetbrains.kotlin:kotlin-stdlib-jre8:1.1.4-3

Pull Request #4 fixes this on master, but the release was never officially made it seems.

This is causing a few jar clashes between Kotlin versions locally.

Cheers

The recently released guice 5.1.0 appears to change something that breaks the way the KotlinMultibinder binds the Set (and I think similar for the way the KotlinMapBinder binds the Map) and it appears that both the guice native multibinder and the kotlin-guice KotlinMultibinder are attempting to set the same binding. Looking at the commit list, probably related to https://github.com/google/guice/commit/e6ec2a4a9433d64e763093a826eecf49f005aa5d and https://github.com/google/guice/commit/a260458b28b2dad9e2c8cfca2a2783e585784ab6 ?

  spek2:KotlinMultibinderSpec:KotlinMultibinder:@ProvidesIntoSet:binds complex types into an annotated set
    => com.google.inject.CreationException: Unable to create injector, see the following errors:
1) [Guice/BindingAlreadySet]: Set<? extends Callable<A>> annotated with @Annotated() was bound multiple times.
Bound at:
1  : KotlinMultibinderSpec$1$1$4$4$injector$1.provideAnnotatedACallable(KotlinMultibinderSpec.kt:298)
      \_ installed by: KotlinMultibinderSpec$1$1$4$4$injector$1 -> RealMultibinder
2  : KotlinMultibinderSpec$1$1$4$4$injector$1.provideAnnotatedACallable(KotlinMultibinderSpec.kt:298)
      \_ installed by: KotlinMultibinderSpec$1$1$4$4$injector$1 -> RealKotlinMultibinder
Learn more:
  https://github.com/google/guice/wiki/BINDING_ALREADY_SET
2) [Guice/BindingAlreadySet]: Set<? extends Callable<A>> was bound multiple times.
Bound at:
1  : KotlinMultibinderSpec$1$1$4$4$injector$1.provideUnannotatedACallable(KotlinMultibinderSpec.kt:309)
      \_ installed by: KotlinMultibinderSpec$1$1$4$4$injector$1 -> RealMultibinder
2  : KotlinMultibinderSpec$1$1$4$4$injector$1.provideUnannotatedACallable(KotlinMultibinderSpec.kt:309)
      \_ installed by: KotlinMultibinderSpec$1$1$4$4$injector$1 -> RealKotlinMultibinder
Learn more:
  https://github.com/google/guice/wiki/BINDING_ALREADY_SET
2 errors
======================
Full classname legend:
======================
A:                                        "dev.misfitlabs.kotlinguice4.multibindings.A"
Annotated:                                "dev.misfitlabs.kotlinguice4.multibindings.Annotated"
Callable:                                 "java.util.concurrent.Callable"
KotlinMultibinderSpec$1$1$4$4$injector$1: "dev.misfitlabs.kotlinguice4.multibindings.KotlinMultibinderSpec$1$1$4$4$injector$1"
RealKotlinMultibinder:                    "dev.misfitlabs.kotlinguice4.multibindings.RealKotlinMultibinder"
RealMultibinder:                          "com.google.inject.internal.RealMultibinder"
========================
End of classname legend:
========================
       com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:576)
       com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:163)
       com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:110)
       com.google.inject.Guice.createInjector(Guice.java:87)
       com.google.inject.Guice.createInjector(Guice.java:69)
       com.google.inject.Guice.createInjector(Guice.java:59)
       dev.misfitlabs.kotlinguice4.multibindings.KotlinMultibinderSpec$1$1$4$4.invoke(KotlinMultibinderSpec.kt:290)
       dev.misfitlabs.kotlinguice4.multibindings.KotlinMultibinderSpec$1$1$4$4.invoke(KotlinMultibinderSpec.kt:37)
       org.spekframework.spek2.runtime.scope.TestScopeImpl.execute(Scopes.kt:94)
       org.spekframework.spek2.runtime.Executor$execute$$inlined$executeSafely$lambda$1$1.invokeSuspend(Executor.kt:52)
       [...]

This upgrades:

• Guice to 5.0.1
• Kotlin to 1.4.32

Guice 5.0.1 replaces cglib which removes a ton of 'illegal reflective access' warnings that previously came from Guice when running it on newer versions of JVM.

I'm testing my module using mocks. I'm not supplying a particular property (somewhere). I get the following error message:

com.google.inject.CreationException: Unable to create injector, see the following errors:

1) Binding to null instances is not allowed. Use toProvider(Providers.of(null)) if this is your intended behaviour.
  at com.authzee.kotlinguice4.internal.KotlinBindingBuilder.toInstance(KotlinBindingBuilder.kt)

1 error

Please ensure you are naming the null property in this message, otherwise it's extremely hard to track down.

Currently, regular bindings can use .annotatedWith(Names.named(name)) to do a named binding, but fall back to regular Guice, rather than kotlin-guice after doing so:

bind<Interface>().annotatedWith(Names.named(name)).to(Implementation::class.java)

instead of being able to do something like:

bind<Interface>().annotatedWith(Names.named(name)).to<Implementation>() or, potentially something like: bind<Interface>().named(name).to<Implementation>()

On the Multibinding support, it doesn't appear that named bindings are supported at all, and need to fall back fully to regular Guice: Multibinder.newSetBinder(binder(), Interface::class.java, Names.named(name)).addBinding().to(Implementation::class.java)

instead of being able to do something like:

KotlinMultibinder.namedSetBinder<Interface>(kotlinBinder, name).addBinding().to<Implementation>()

Including the JRE package results in Gradle build warnings about it being deprecated. See http://kotlinlang.org/docs/reference/whatsnew12.html#kotlin-standard-library-artifacts-and-split-packages.

Hi,

Small PR with a few updates to kotlin, guice, and other dependencies.

I've removed the separate multibinding module because since guice 4.2 it's part of core. Moved everything related to multibinding into the main module.

Let me know what you think.

Cheers.

With Guice 4.2 the guice-multibindings extension was merged into Guice core. This commit mirrors that change such that the kotlin-guice-multibindings files are not part of kotlin-guice and the kotlin-guice-multibindings module has been removed.

the extensive use of this function:

https://github.com/misfitlabsdev/kotlin-guice/blob/7d2a0523b4449da0b2d80e1217a052a3d881753d/kotlin-guice/src/main/kotlin/dev/misfitlabs/kotlinguice4/TypeLiteral.kt#L29

means you are going to end up with a lot of class files pretaining to anonymous overloads. The TypeLiteral hack was added by google as a clever way to avoid type-erasure.

But in a library such as this, I believe you should use java.lang.reflect.Type and kotlin.reflect.KType, which each do not suffer from type-erasure and will not require any additional *.class files.

If you're unfamiliar with java.lang.reflect.Type, its effectively wrappers on fully-qualified class strings such as "java.util.ArrayList<? extends java.lang.String>" and they can be used to preserve generic info, making them the obvious choice for guice-binding logic, they're just difficult for users to handle correctly.

I suggest using something like this:

inline fun <reified T> kotlinTypeKey(
        annotation: Annotation? = null,
        annotationType: KClass<out Annotation>? = null
): Key<T> {
    if(annotation != null) require(annotationType == null)
    if(annotationType != null) require(annotation == null)

    val ktype = typeOf<T>()
    val baseType = ktype.javaType

    val result = when {
        annotation != null -> Key.get(baseType, annotation)
        annotationType != null -> Key.get(baseType, annotationType.java)
        else -> Key.get(baseType)
    }

    @Suppress("UNCHECKED_CAST")
    return result as Key<T>
}

Once completed, there should be a (measurable) reduction in class files and possibly a measurable increase in performance, particularly for slow hard-drive computers using *.class file distributions (rather than jar distributions).

an implementation note:

while this is technically 1.3 compatible, on 1.3.61 the javaType extension in kotlin-jvm will throw. Unfortunately this cant be solved via a simple if-statement because if you expose

public inline fun <reified T> someBindWrapper(...) {
  if(version == "1.4") {
    //do lightweight j.l.r.Type & KType binding
    doBinding(typeOf<T>())
  }
  else {
    //use heavyweight anonymous typeLiteral overload
    doBinding(object: TypeLiteral<T>(){}) //<-- generates a class file
  }
}

then, of course, because the if statement cannot be done at compile time, the compiler will generate the class files that we're trying to avoid in the first place! While the native community might solve this with something like #IFDEF KOTLIN_1_4, for better and for worse we have no such device

I'm really not sure what an elegent solution here is:

• You could of course create a separate release for 1.4+ and 1.0-1.3, but that's cloogy and opens the door for version hell.
• You could simply wait to introduce such a patch until 1.4 becomes main-stream, and then add a hard-dependency on kotlin 1.4.
• You could shadow (read: copy and paste into a new package) the javaType extension function from 1.4. Its not huge and its not too dependent on kotlin 1.4, but it is a reasonably sophisticated string parser and it is responsible for mapping things like kotlin.String to java.lang.String, and kotlin.collections.List<A> to java.util.List<? extends A>.

Anyways, if you're interested, I'd be happy to give an implemenation a try and issue a pull request!