What is his argument? Lesser code base? Easier to match problem property to relative json key?

probably something like this -> https://publicobject.com/2016/01/20/strict-naming-conventions-are-a-liability/ (And I agree, though it’s ok with an explicit annotation)

Java

interface ConstantsJ {
    String CONSTANT_J_1 = "J1";
}

Kotlin

object ConstantsK : ConstantsJ {
    const val CONSTANT_K_1 = "K1"
}
// in another class:
import mypackage.ConstantsK.CONSTANT_K_1 // works
import mypackage.ConstantsK.CONSTANT_J_1 // cannot resolve symbol

Why? Shouldn't have

ConstantsK

object inherited constants from

ConstantsJ

interface?

@lovis Thanks for the article, because I can't find something in favour of opposite point of view)

Silly question, does anyone have maybe like a guide to resolving classpath issues? I have a project that builds successfully and spits out a runnable (shaded) JAR, but I’m getting this bizarre

java.lang.AbstractMethodError: Method org/eclipse/jetty/server/HttpChannelOverHttp.contentComplete()Z is abstract

that afaik is being caused by something I’ve misconfigured somewhere

could be dependency conflict and picked differend one during compile then in the shaded jar

Ah, maybe, is there maybe a maven feature/plugin that can detect that at build time?

maybe it’s in the

-X

output

dependency:tree

I’ll give that a shot 👍

ah, neat, thank you!

Hmm, anyone have some experience w/ multi-module projects? I have a sneaking suspicion I’m doing this wrong™

with ... gradle? maven?

@evanchooly My bad, Maven, shaded jar

running into what seems like classpath/dependency problems

hrm. just read the backlog. i've not seen anything like that... maybe conflicting versions of jetty?

I’ve only included one dependency that should only pull the one version of Jetty down, plus the enforcer plugin seems to care more about

kotlin-stdlib-jre8

more than Jetty

I think I’m misunderstanding how dependency inheritance works

you mind if I paste a project structure in here?

#build-tools maybe?

good point

Anyone know of a way to iterate through the subclasses of a sealed class at run time? or is it only a compile time construct?

@stantronic Maybe with kotlin reflection library (warning, it's huge, to consider if you're not already using it, especially on Android)

@stantronic Also, maybe Java reflection allows you to lookup for subclasses, which should then work with sealed classes too

okay thanks 🙂

Java reflection doesn't let you look for subclasses as far as I know

maybe Kotlin reflection metadata has that

You can only look up super classes. For subclasses you might want to look into classpath scanning.

yeah, there's stuff like the reflections library that just looks for classes across your whole classpath but I think that's inefficient in performance