Hello, I upgraded the JDK from 1.8 to 11. Is there...

# gradle

[Giorgio Antonioli]

Hello, I upgraded the JDK from 1.8 to 11. Is there a way to use the 1.8 sources and compile towards 1.8? I’ve used kotlinOptions.jvmTarget = "1.8" but I can still access the JDK 11 classes. To make a clear example: the API AccessibleObject.isAccessible is deprecated since 9. I’d like to still use the source of 1.8 in which that API is not deprecated.

[Michael]

This is dependent on your runtime. If you use Java 1.8 tu run the Program you can still use the method. Also if you use 11 as your Runtime you can still use it as it is still in the stdlib even though it's deprecated.

As once you upgrade to a JDK version which actually removed it you won't be available anymore it would be worth a shot migrating to AccessibleObject#canAccess(Object) or to use the KCallable.isAccessible extension

[Giorgio Antonioli]

Thanks for the answer. The problem I’m facing though is: how can I ensure I produce bytecode fully compatible with 1.8? For example, the API AccessibleObject.canAccess() is available only since 9. This means that if I replace AccessibleObject.isAccessible with AccessibleObject.canAccess() , the program will crash at runtime when run on 1.8. Obviously AccessibleObject.isAccessible is just an example of the problem

[Michael]

the best possible solution would probabbly to use the new jpackager tool to just bundle it with java 11

[Michael]

Another way is to do multiple implementations which will only work as long the compile java version still has the method in the JDK
If that is no longer possible you would need multiple modules and compile them with older versions of the JDK or call it via reflections which would both be really complicated

[Giorgio Antonioli]

Oh ok, so there’s no way to enforce it with the Kotlin plugin for example. Unfortunately I can’t use jpackager since I’m on Android. The issue happens on a JVM-only module in a multi-module project. The Android app depends on this module

[Michael]

I never worked with the android SDK that deeply but iirc android has it's own sdk containing a st5dlib so you should not be dependent on java stdlib methods

[Giorgio Antonioli]

The problem happens only in JVM-only modules, so that module isn’t related to Android. It produces a jar which will be embedded in Android app. That’s why I can’t use solutions like jpackager unfortunately. I thought that kotlinOptions.jvmTarget or sourceCompatibility /`targetCompatibiliy` behaved in the way I was expecting in the first post

[Michael]

that only affects the generated bytecode and not the stdlib

[Giorgio Antonioli]

oh ok thanks for the explanation

[ephemient]

https://youtrack.jetbrains.com/issue/KT-29974

[Giorgio Antonioli]

@ephemient Thanks very much to have pointed out this issue. That is exactly what I was asking for

[ilya.gorbunov]

@Giorgio Antonioli you can use jdkHome option from kotlinOptions to specify path to JDK that is used to resolve JDK API

[Giorgio Antonioli]

@ilya.gorbunov Thanks, we already applied this solution, but I was searching a way to enforce it automatically for all the developers on the same project