Question: Working Hot Reload Setup?

[ecnaidar]

Hey, first of all, thank you for your work on bringing Vaadin to Kotlin! Especially amazing to see brewity Karibu DSL brings to creating views and reusable components ❤️

With that said, do you know if it is possible to get hotreload setup working with Kotlin and Karibu? (or perhaps some misconfiguration that causes the issue for me?)

We have a project based on VoK helloworld app and I could not get hotreload working on IntelliJ Community in a reasonable way with any of proposed solutions either from your Vaadin Boot or Vaadin docs so I would appreciate any comments or pointers if such setup exists.

• With JBR and all flags it is working but extremely inconsistent (e.g. 99% chance that any changes to Karibu DSL layouts will require a full restart)
• running directly Main.kt or through the Gradle's run task does not seem to make much difference
• Adding in Hotswap agent with fatjar reload causes a wall of errors right from the startup and tsunami of errors on rebuild 😢
• I reckon that spring-boot-devtools are completely irrelevant when using Vaadin Boot
• JRebel licensing is quite steep and not quite sure if it would work as well, so did not explore further

again, dependency-wise it is forked from VoK helloworld app and while I updated some of dependencies and added others, it should not affect but posting gradle.kts here just in case it could give any information

Thank you for your time and any suggestions are welcome.

plugins {
    kotlin("jvm") version "1.8.0"
    id("com.vaadin") version "24.1.11"
    application
    id("com.avast.gradle.docker-compose") version "0.16.2"
}

defaultTasks("clean", "build")

repositories {
    mavenCentral()
}

dependencies {
    val VAADIN_VERSION = "24.1.11"
    val VOK_VERSION = "0.16.0"
    // Vaadin
    implementation("eu.vaadinonkotlin:vok-framework-vokdb:${VOK_VERSION}")
    implementation("com.vaadin:vaadin-core:${VAADIN_VERSION}") {
        afterEvaluate {
            if (vaadin.productionMode) {
                exclude(module = "vaadin-dev")
            }
        }
    }
    implementation("com.github.mvysny.vaadin-boot:vaadin-boot:12.0")
    implementation("com.github.mvysny.vaadin-simple-security:vaadin-simple-security:0.2")
    implementation("com.github.mvysny.vokorm:vok-orm:2.0")
    // REST
    implementation("eu.vaadinonkotlin:vok-rest:${VOK_VERSION}")

    // logging
    // currently we are logging through the SLF4J API to SLF4J-Simple. See src/main/resources/simplelogger.properties file for the logger configuration
    implementation("org.slf4j:slf4j-simple:2.0.6")

    // db
    implementation("com.zaxxer:HikariCP:5.0.1")
    implementation("org.flywaydb:flyway-core:9.15.2")
    implementation("org.postgresql:postgresql:42.6.0")

    // ldap
    implementation("com.unboundid:unboundid-ldapsdk:6.0.9")

    // Kotlin
    implementation(kotlin("stdlib-jdk8"))

    implementation("org.springframework.boot:spring-boot-devtools:3.0.6")
}

java {
    sourceCompatibility = JavaVersion.VERSION_17
    targetCompatibility = JavaVersion.VERSION_17
}

tasks.withType<KotlinCompile> {
    kotlinOptions.jvmTarget = "17"
}

tasks.withType<Test> {
    useJUnitPlatform()
    testLogging {
        // to see the exception stacktraces of failed tests in CI
        exceptionFormat = TestExceptionFormat.FULL
    }
}

[mvysny]

Thank you so much, I'm really happy that you like Vaadin-on-Kotlin :)

Unfortunately I have found no good solution for the hot-redeployment. I think it's connected to the massive number of closures/anonymous classes outputted for every dsl{} block; the classes change every time the hierarchy is changed. It's just a hunch, I have no proof or anything.

I also ended up using the JBR with all of the flags as mentioned with https://github.com/mvysny/vaadin-boot#advanced-hotswapping , but I'm mostly ending up with having to restart the JVM unfortunately. The JRebel pricing is too steep, and I'm not sure whether the hot-redeployment is actually better or not.

I wonder whether JBR 21 will have improved hot-redeployment... Maybe we can try to build JBR21 from https://github.com/JetBrains/JetBrainsRuntime/tree/jbr21 and try it out.

Let's keep this question open, maybe others have found a better solution.

[ecnaidar]

mostly ending up with having to restart the JVM

Yeah, sounds like a familliar sitation. Seems to work just fine when you only touch non-DSL classes or changing configs inside of existing DSL structures. Not sure if it depends on the depths, I will keep an eye out for it.

Thanks for the fast response on this anyway and let's see if situation improves in the future 👍