<@U0QBCLV62> Do you have any suggestions for how t...

# gradle

[jlleitschuh]

@bamboo Do you have any suggestions for how to work with the JDK 9 issue? I can't get the build to work with JDK 9 so I can't really make meaningful changes/development.
Its a catch 22.

[bamboo]

I think the next step would be to make sure a standalone Kotlin script consumer project works

[bamboo]

Know what I mean? A small repro against the Kotlin compiler API

[jlleitschuh]

Hrm... So generate Gradle from the Kotlin-Dsl project and then try that version of Gradle with this small repro project?
Does not sound like it would allow for fast iteration time.

[bamboo]

No, no

[bamboo]

I mean a standalone Kotlin project that consumes the Kotlin API (just like the kotlin-dsl project does) to compile a script and run it on JDK 9. No gradle-kotlin-dsl involved.

[bamboo]

The point is to prove the foundation works before debugging Gradle and kotlin-dsl issues.

[jlleitschuh]

Ohh. Just get a simple script that can be consumed and working under JDK 9.
Not even gradle based.

[bamboo]

Exactly.

[bamboo]

And then if that works, we’ll have to figure what’s the different in how we use the compiler.

[jlleitschuh]

Is there independent support for kotlin scripting outside of gradle? The #scripting channel seems pretty dead.

[bamboo]

There is some and scripting support is about to become official.

[jlleitschuh]

Hrm...
I've tried working with the kotlin repository before and the thing is a beast. Not well documented and not easy to figure out how to run the example tests. /rant

It make sense to work on this problem in isolation but it would be good if any tests against JDK 9 could be integrated into the kotlin repo so that there aren't regressions in the scripting handler.

[jlleitschuh]

Is JDK 9 support a Kotlin DSL 1.0 priority?

[bamboo]

Yes

[jlleitschuh]

I like your idea of compartmentalizing the problem. That seems like the right approach.

Do you have some basic dummy project with all of the boilerplate already setup for scripting testing?

[bamboo]

I think I do

[bamboo]

Let me see

[bamboo]

yeah, I’ve found something that needs to be updated to the latest API, I’ll do that later and ping you

[jlleitschuh]

Thanks. I may have some time to tinker with the problem this weekend. Or even later today if I'm able to finish up some other stuff.

[bamboo]

https://github.com/bamboo/kotlin-sam-with-receiver-repro

[bamboo]

The 1st goal would be to try to run the resulting application under Java 9

[bamboo]

To be perfectly clear, not running the build itself under Java 9 but the resulting application

[bamboo]

By application, I mean the one produced by the compiler subproject

[bamboo]

(it uses the application plugin)

[jlleitschuh]

Yea, I think we're on the same page there.
I'll probably copy your code into a gradle build that's written in groovy to test this.
It doesn't seem that your example reads in a script from any sort of resource.

[bamboo]

Which script?

[bamboo]

You can run the build with Java 8 and then run the resulting app with Java 9, no?

[jlleitschuh]

Oooooh! I see. Sure, but it would be easier to test/write unit tests/debug in IntelliJ if I could execute the entire enviroment under JDK 9

[jlleitschuh]

Isn't this code calling the kotlin script compiler? Doesn't it need to compile a file? Or can you just pass it a multiline string?

[bamboo]

https://github.com/bamboo/kotlin-sam-with-receiver-repro/blob/master/compiler/src/main/kotlin/compiler/Main.kt#L30

[jlleitschuh]

Oh hey. Cool.
I probably shouldn't be trying to also get gradle to work. I just want a stupid script to work without the extra complexity of dealing with gradle.

So just getting a script to compile and run with a method.
Then perhaps introduce a dependency that I want to be on the classpath after that.

[bamboo]

That app doesn’t use Gradle

[bamboo]

It emulates the Gradle use-case closely though

[jlleitschuh]

Oh! Really! Okay then!

[jlleitschuh]

That's good to know!

[jlleitschuh]

@bamboo I'm beginning work on testing this here:
https://github.com/JLLeitschuh/kotlin-scripting-jdk9

[jlleitschuh]

So I figured out how to at least get the script file to compile but now I'm getting a problem from the Kotlin Script code generator.

[jlleitschuh]

Exception in thread "main" java.lang.RuntimeException: Primary constructor not found for script template class BuildScript (not found)
	at org.jetbrains.kotlin.codegen.ScriptCodegen.genConstructor(ScriptCodegen.java:157)
	at org.jetbrains.kotlin.codegen.ScriptCodegen.generateBody(ScriptCodegen.java:103)
	at org.jetbrains.kotlin.codegen.MemberCodegen.generate(MemberCodegen.java:145)
	at org.jetbrains.kotlin.codegen.PackageCodegenImpl.generateFile(PackageCodegenImpl.java:120)
	at org.jetbrains.kotlin.codegen.PackageCodegenImpl.generate(PackageCodegenImpl.java:66)
	at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.generatePackage(KotlinCodegenFacade.java:99)
	at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.doGenerateFiles(KotlinCodegenFacade.java:77)
	at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.compileCorrectFiles(KotlinCodegenFacade.java:44)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.generate(KotlinToJVMBytecodeCompiler.kt:442)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyzeAndGenerate(KotlinToJVMBytecodeCompiler.kt:359)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileScript(KotlinToJVMBytecodeCompiler.kt:331)
	at compiler.KotlinCompilerKt.compileKotlinScriptToDirectory(KotlinCompiler.kt:49)
	at compiler.Main.main(Main.kt:44)

[jlleitschuh]

Okay, I solved that error

[jlleitschuh]

My sanity test. All of this code still does work under JDK 8.

[jlleitschuh]

@bamboo This bit of code you have here no longer works on JDK 9
https://github.com/bamboo/kotlin-sam-with-receiver-repro/blob/master/compiler/src/main/kotlin/compiler/Main.kt#L63-L67

javaClass.classLoader no longer returns a URLClassLoader so that cast fails.

[jlleitschuh]

I ended up changing it to this wacky bit of code here:

private
    val classPath: List<File>
        get() {
            println("Getting Classpath")
            val classPath = listOf(
                api.Action::class,
                kotlin.PublishedApi::class,
                kotlin.reflect.KClass::class,
                Resolver::class
            ).map {
                it.java.protectionDomain.codeSource.location.toURI()
            }.map {
                File(it)
            } + PathUtil.getJdkClassesRootsFromCurrentJre()

            println("Got classpath: $classPath")
            return classPath
        }

[jlleitschuh]

I'm going to write up a YouTrack issue. Pavel Talanov offered to take a look at this issue tomorrow.

[bamboo]

Usually the call to PathUtil.getJdkClassesRootsFromCurrentJre() is not needed

[bamboo]

Very good to know about the classloader change

[bamboo]

Keep up the good work, @jlleitschuh, thanks!

[jlleitschuh]

The thing is that code still doesn't work. The PathUtil thing is a failed attempt to get it to work. I could remove it and have the same behavior. (I probably should from my repo)

[bamboo]

Niiiice

[jlleitschuh]

@bamboo What do you think of this comment? Seems to imply that GSK should try to use the command line interface, which seems kind of wacky.
You won't be able to attach a message collector to it that way.
https://youtrack.jetbrains.com/issue/KT-20167#comment=27-2412729

Also, do you want me to implement the stopgap fix in a PR so that we can get a build of Gradle with the fix. That way we can test everything under JDK 9 on Travis.

[bamboo]

Thanks, @jlleitschuh, just reviewed it.