Can't set jvm-target option on Kotlin Compiler #84

Activity

1. holgerbrandl commented on Jan 6, 2018

   

   holgerbrandl

   on Jan 6, 2018

   Collaborator

   More actions

   Could you attach an example?
2. jmmk commented on Jan 6, 2018

   

   jmmk

   on Jan 6, 2018

   Author

   More actions

   MyScript.kt:

   #!/usr/bin/env kscript
   
   @file:DependsOn("org.jetbrains.kotlin:kotlin-reflect:1.1.60")
   @file:DependsOn("com.github.kittinunf.fuel:fuel-jackson:1.12.0")
   
   import com.fasterxml.jackson.databind.DeserializationFeature
   import com.fasterxml.jackson.databind.ObjectMapper
   import com.fasterxml.jackson.module.kotlin.jacksonObjectMapper
   import com.github.kittinunf.fuel.Fuel
   import com.github.kittinunf.fuel.jackson.responseObject
   
   
   val mapper: ObjectMapper = jacksonObjectMapper()
       .disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
   
   data class User(val id: String, val name: String)
   fun main(args: Array<String>) {
       val (_, _, result) = Fuel.get("https://jsonplaceholder.typicode.com/users").responseObject<User>()
   }

   running ./MyScript.kt produces:

   [kscript] [ERROR] compilation of './MyScript.kt' failed
   MyScript.kt:18:81: error: cannot inline bytecode built with JVM target 1.8 into bytecode that is being built with JVM target 1.6. Please specify proper '-jvm-target' option
       val (_, _, result) = Fuel.get("https://jsonplaceholder.typicode.com/users").responseObject<User>()
                                                                                   ^
   
3. holgerbrandl commented on Jan 8, 2018

   

   holgerbrandl

   on Jan 8, 2018

   Collaborator

   More actions

   Same for me.

   The kotlinc default is 1.6 for a reason (I guess/hope), so simply using 1.8 as kscript default feels a bit inconsistent. However, the main motivation for using 1.6 is most likely android compatibility, which does not matter with respect to kscript, so maybe using 1.8 is not so wrong after all.

   At the moment compiler flags used by kscript can't be adjusted. We could add another directive (e.g. named @CompilerOpts) to allow the user to adjust compiler behavior if needed.

   What do you think?
4. jmmk commented on Jan 8, 2018

   

   jmmk

   on Jan 8, 2018

   Author

   More actions

   @holgerbrandl I think that makes sense. There's @KotlinOpts to configure runtime flags, so something like @CompilerOpts or @KotlincOpts would be nice to configure compiler flags
5. jasoet commented on Feb 1, 2018

   

   jasoet

   on Feb 1, 2018

   More actions

   +1
6. sail-y commented on Feb 7, 2018

   

   sail-y

   on Feb 7, 2018

   More actions

   +1
7. holgerbrandl

   closed this as completedin c23d575on Feb 9, 2018