Thanks for the information and link Damian. This i...

# announcements

[edalorzo]

Thanks for the information and link Damian. This is interesting. I suppose this means there are no runtime guarantees regarding internal. While I was waiting for someone to comment I wrote a small internal function.

internal fun hello(name: String): String {
  return "Hello " + name
}

compiled it with kotlinc (1.0.6-release-127) and then disassembled it

public final class DemoKt {
  public static final java.lang.String hello(java.lang.String);
    descriptor: (Ljava/lang/String;)Ljava/lang/String;
    Code:
       0: aload_0
       1: ldc           #9                  // String name
       3: invokestatic  #15                 // Method kotlin/jvm/internal/Intrinsics.checkParameterIsNotNull:(Ljava/lang/Object;Ljava/lang/String;)V
       6: new           #17                 // class java/lang/StringBuilder
       9: dup
      10: invokespecial #21                 // Method java/lang/StringBuilder."<init>":()V
      13: ldc           #23                 // String Hello
      15: invokevirtual #27                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      18: aload_0
      19: invokevirtual #27                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      22: invokevirtual #31                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
      25: areturn
}

And it looks like it produced just a regular public function.

[cedric]

edalorzo: In my experience, the impact of internal is more for name resolution that at the bytecode level, and it’s related to the hidden -friendPaths option

[edalorzo]

I see your point. Is that -friendPaths compiler or kotlin runtime option? It must be very well hidden, I was not able to find any information about it. Although I do see some code in the KotlinToJVMByteCodeCompiler 🙂

[cedric]

@edalorzo I like "fiendPaths" 🙂 More seriously, it's not exposed by the command line, you can only access it if you invoke the Kotlin compiler directly from Kotlin. I had to do that for Kobalt to be able to run tests with a dependency on the main module (without that, the tests can't access internal functions)