Hey! Ktor 3.0 forces us to release Prepared 2.0. I...

# opensavvy

[CLOVIS]

Hey! Ktor 3.0 forces us to release Prepared 2.0. If there's anything you'd like to see improved in Prepared 2.0, it's time to tell! I don't want to make breaking changes unless I'm forced to

[CLOVIS]

cc @dave08

[CLOVIS]

The only thing I have in mind is moving the randomness stuff to its own package (in the same module) because it kinda pollutes the documentation, but that's fairly minor

[dave08]

Java 11 for android support might be nice...

[CLOVIS]

Higher Java versions aren't supported even for tests? 😓

[dave08]

for sure tests run on devices don't support them... but I don't think you can even configure a test module to run on a seperate toolchain...? (maybe between modules yes?) And I really have to compile the actual code with at most 11... and even 11 isn't completely desugared (because it's really compiled back to 1.8 behind the scenes, and they support the main 11 api...)

[dave08]

According to chatgpt it's possible for just testing without Robolectric (or AndroidX's testing framework) where you don't need an Android context or any other Android api... but for running with Android api (faked by Robolectric), they might not yet support all java versions... https://chatgpt.com/share/6756cda5-5038-8011-bfab-04f5d15ddd52

[dave08]

Do you really use java features higher than 11?

[dave08]

Another great improvement would be to allow nested tests at least for jvm...! It's so much easier to browse through large tests suites in Intellij that way...

[CLOVIS]

Do you really use java features higher than 11?

I don't really know… And I don't know either which dependencies I have depend on 11+. The problem is I maintain a lot of projects, and I want them to be consistent, so they need to all depend on the same JDK version.

It's already a problem with libraries like Kotest. I can't support WASI even in Prepared Suite because it is tested using Kotest, and Kotest doesn't support it…

[dave08]

I'd maybe try to compile them all with 11... chances are you're not using much later than that... but anyways Prepared seems to be quite isolated from the rest... so it might not hurt to use a different java version.

I can't support WASI even in Prepared Suite because it is tested using Kotest, and Kotest doesn't support it…

😵‍💫 Yeah, that's not so nice... https://github.com/kotest/kotest/issues/4015, it's still open...

[dave08]

I don't think I ever had problems compiling projects with newer java versions that had libs with older ones... but I could be wrong?

[CLOVIS]

Well 8→9 was a big deal. But that's far in the past now.

[CLOVIS]

If you want to try it out, go ahead: clone Prepared and add

kotlin {
    jvmToolchain(11)
}

at the very end of each build.gradle.kts and see what happens

[CLOVIS]

At the very least compat-filesystem will not work (including all the resource stuff) because of Path , but maybe the other modules could be compatible with Java 11

[CLOVIS]

This may be a concern too, but I don't have an answer: https://kotlinlang.slack.com/archives/C7L3JB43G/p1733754600812249

[dave08]

From chatgpt 4o:

Path Features and Limitations in Java 11
No Built-in Watcher for Individual Path:

While Java provides the WatchService API to monitor file system changes, it does not directly support watching changes on an individual Path object. Instead, you need to monitor directories.
No File Metadata Beyond Basics:

The Path API itself does not provide methods for reading extended file attributes or metadata beyond what is supported by the BasicFileAttributes. For more advanced metadata, you need to use Files.getFileAttributeView or similar approaches.
No Automatic Path Normalization:

Path objects do not automatically normalize themselves. For example, if a Path contains redundant elements like . or .., you need to explicitly call .normalize() to remove them.
No Network Resource Support:

The Path API is designed for file system paths and does not support paths for network resources (e.g., <http://example.com/file>). For handling such URIs, you would use the java.net.URI or similar APIs.
No Built-in Support for Path Serialization:

While you can convert a Path to a String using toString() or a URI using toUri(), the Path API itself does not provide direct serialization or deserialization methods. You need to handle this manually.
No In-Memory Virtual Path Support:

Path is tied to the underlying file system and does not support virtual or in-memory paths. For in-memory file systems, you would need third-party libraries like Jimfs.
Platform-Specific Behaviors:

Some methods, like toAbsolutePath(), rely on the underlying operating system's behavior, which might lead to platform-specific differences.

[dave08]

Otherwise, it seems like it was introduced in Java 7

[dave08]

And it claims that Kotlin Path extensions only depend on the Java 7 implementation...

[dave08]

@CLOVIS I tried adding jvmToolchain(11) to all the modules (except the gradle testing module... which doesn't really make a difference in my case), but I seem to get an error in something completely different:

> Task :compat:compat-parameterize:linkDebugTestMingwX64
e: Compilation failed: Error occurred while optimizing an expression:
CALL 'public abstract fun <get-name> (): kotlin.String declared in kotlin.reflect.KCallable' type=kotlin.String origin=GET_PROPERTY
  $this: PROPERTY_REFERENCE 'private final currentIterationScope: com.benwoodworth.parameterize.ParameterizeScope? [var] declared in com.benwoodworth.parameterize.ParameterizeIterator' field=null getter='private final fun <get-currentIterationScope> (): com.benwoodworth.parameterize.ParameterizeScope? declared in com.benwoodworth.parameterize.ParameterizeIterator' setter='private final fun <set-currentIterationScope> (<set-?>: com.benwoodworth.parameterize.ParameterizeScope?): kotlin.Unit declared in com.benwoodworth.parameterize.ParameterizeIterator' type=kotlin.reflect.KMutableProperty0<com.benwoodworth.parameterize.ParameterizeScope?> origin=null


 * Source files: 
 * Compiler version: 2.0.20
 * Output kind: PROGRAM

e: java.lang.AssertionError: Error occurred while optimizing an expression:
CALL 'public abstract fun <get-name> (): kotlin.String declared in kotlin.reflect.KCallable' type=kotlin.String origin=GET_PROPERTY
  $this: PROPERTY_REFERENCE 'private final currentIterationScope: com.benwoodworth.parameterize.ParameterizeScope? [var] declared in com.benwoodworth.parameterize.ParameterizeIterator' field=null getter='private final fun <get-currentIterationScope> (): com.benwoodworth.parameterize.ParameterizeScope? declared in com.benwoodworth.parameterize.ParameterizeIterator' setter='private final fun <set-currentIterationScope> (<set-?>: com.benwoodworth.parameterize.ParameterizeScope?): kotlin.Unit declared in com.benwoodworth.parameterize.ParameterizeIterator' type=kotlin.reflect.KMutableProperty0<com.benwoodworth.parameterize.ParameterizeScope?> origin=null

[dave08]

I'm running on Ubuntu Budgie.

[dave08]

I'll try to stash the changes and build again to see if I get the same error.

[dave08]

Ok, the build succeeded w/o the changes... but linkDebugTestMingwX64 has nothing to do with the jvmToolchain... 🤔

[dave08]

Ok, for some reason, after building w/o the changes, when I build with them, the build succeeds...

[dave08]

Now I'm trying ./gradlew clean build

[dave08]

That was also successful. So I guess there's no problem in using java 11 then @CLOVIS?

[dave08]

It's just a bit funny I got that error initially, but it could be that intellij tried compiling the project before gradle and did something wrong...

[CLOVIS]

That error is really weird… but I don't see how it could ever be related

[dave08]

But in the end, it compiled successfully with ./gradlew clean build so I don't think it matters, no?

[CLOVIS]

So, to summarize my thoughts on Java 11:
• Decreasing the JDK version will probably introduce problems because things I was using won't be available anymore → though it seems that for the Prepared repository, this isn't particularly an issue, decreasing it for all other repositories is going to be quite some work and it's likely that we'll need to give up halfway if one of them is stuck
• Having different JDK versions for different repositories will be a pain to upgrade when new versions are released. Currently, the policy is: Gradle plugins target 11, libraries target the previous long-term JDK (currently 17), applications target the previous stable JDK (currently 22). This is all configured in the Gradle conventions, so it's easy to migrate the entire OpenSavvy fleet
• The main reason for the downgrade is for Android support. It seems strange to me that I haven't heard other library authors complain about this, how do they manage that? Shouldn't desugaring manage all of this?
• Recent JDK versions have more bytecodes that can optimize some scenarii. Though as we mentioned, it appears the Kotlin compiler doesn't take advantage of that many of them. The main one I'm a bit worried about is that pre-17 sealed classes are not sealed as viewed from Java. So it becomes a question of deciding what is more important: supporting Java users, or supporting Android users. Prepared is meant specifically for Kotlin, but Pedestal must be usable from Java as well.

[dave08]

It's really up to you, but in my opinion, a testing framework is conceptually different from Pedestal... (although if it's already KMP, it seems you do care that it should be compatible for mobile use -- including Android -- but it might just be too much of a headache to start going back).

I don't think anyone needs to talk about Android not supporting more than 11, since it's in the docs: https://developer.android.com/build/jdks#compileSdk

[dave08]

See: https://composables.com/android-distribution-chart
only 13% would support java 17 at this moment...

[dave08]

And even that, is only core libraries support, like in the previous link

[CLOVIS]

😕

[CLOVIS]

Thing is, Prepared is one thing, but if there really is no way to use my libs in Android, I need to downgrade them all

And that… I don't know if I even can

[dave08]

Yeah... 🤕 😵‍💫 🤷🏽‍♂️... that's Android for you...

[dave08]

Eventually people will upgrade their devices, but it takes ages... there's also lots of companies out there that buy devices for their workers, and until they upgrade..................... we deal with a bunch of those 🤒

[CLOVIS]

Honestly, I thought 17 was for sure a safe bet, it's not that recent either

[CLOVIS]

I personally mostly do backend, and we don't want to lag too much behind new JDK versions because there's always interesting stuff

[dave08]

That's what I said, it's really up to you... it would be a pity for Android devs, but I'm just a bit skeptic on how it would help in practice, I think Kotlin Test is supported, but I know that Robolectric tests so far doesn't have official support for Junit 5, even Kotest might not support it... so it might really only be for unit tests... which could potentially be run on a newer java, but it's always good to stay as close to the setup of your production code as possible for tests...