# announcements
So many haters in comments 🙂
I mean, they all have valid points. I don't think Kotlin will just magically vanish or turn into a mess, torn between following Java and having its own style, but it's definitely something to consider
Top comment even didn't try to google, I didn't read it fully, but starting from the first point it's wrong 🙂 https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-metadata/
And obviously top commenter didn't know about Kotlin design process and history of patter matching in Kotlin 🙂
Now, both java and kotlin cater to this use case, they cater to it in a different way, and I'm pretty sure that if I could smack a giant reset button and design kotlin all over again and release it today into public beta, then kotlin would have followed in java's shoes. Especially considering that the java version is in many ways far more powerful than kotlins: You can do more than just 'check type' with this syntax (you can also 'deconstruct' value types), you don't NEED a block, as in, this works too:
That happens when people start comparing things they didn't know equally good
@irus I for sure can’t get anything about the metadata spec from the link you provide. It only gives an input of metadata format. Nothing about content
Hm, I can map doc to this example from my class
Copy code
   mv = {1, 4, 3},
   bv = {1, 0, 3},
   k = 1,
   d1 = {"\u0000*\n\u0002\u0018\u0002\n\u0002\u0018\u0002\n\u0000\n\u0002\u0018\u0002\n\u0000\n\u0002\u0018\u0002\n\u0002\b\u0002\n\u0002\u0010$\n\u0002\u0010\u000e\n\u0002\b\u0005\n\u0002\u0010\u0002\n\u0000\u0018\u00002\u00020\u0001B\u0015\u0012\u0006\u0010\u0002\u001a\u00020\u0003\u0012\u0006\u0010\u0004\u001a\u00020\u0005¢\u0006\u0002\u0010\u0006J\b\u0010\u000e\u001a\u00020\u000fH\u0016R&\u0010\u0007\u001a\u000e\u0012\u0004\u0012\u00020\t\u0012\u0004\u0012\u00020\t0\bX\u0096\u000e¢\u0006\u000e\n\u0000\u001a\u0004\b\n\u0010\u000b\"\u0004\b\f\u0010\rR\u000e\u0010\u0002\u001a\u00020\u0003X\u0082\u0004¢\u0006\u0002\n\u0000R\u000e\u0010\u0004\u001a\u00020\u0005X\u0082\u0004¢\u0006\u0002\n\u0000¨\u0006\u0010"},
   d2 = {"Llink/kotlin/repo/GithubConfigurationService;", "Llink/kotlin/repo/ConfigurationService;", "httpClient", "Lorg/apache/http/client/HttpClient;", "yamlMapper", "Lcom/fasterxml/jackson/databind/ObjectMapper;", "(Lorg/apache/http/client/HttpClient;Lcom/fasterxml/jackson/databind/ObjectMapper;)V", "configuration", "", "", "getConfiguration", "()Ljava/util/Map;", "setConfiguration", "(Ljava/util/Map;)V", "update", "", "repo.kotlin.link.main"}
Idk what I want to get from it, because this is basically info that compiler can't infer from classfile (or it's easier to put as ready-to-use metadata)
Sure, but what does this contain? d1? d2? And why, and for what? How would any other code editor than IntelliJ make use of this?
From the doc:
This annotation is present on any class file produced by the Kotlin compiler and is read by the compiler and reflection
It's has nothing with intellij itself
All details on how to use can be found in kotlin repo (compiler is apache 2.0 licensed)
IntelliJ needs this info also in order to provide debugging i guess. But - my main point is your only effort so far is to try and discredit the post, not discuss it.
👎 1
IntelliJ needs this info also in order to provide debugging i guess.
Debugging built on top of JDI, and probably can't benefit from @metadata directly
It should be implementation detail, and PSI or IR exposes it's through their interface.
I believe this is content of d1 if you really interested https://github.com/JetBrains/kotlin/blob/master/core/metadata/src/metadata.proto
And I found it even without cloning the project, just browsing repo in github)
JFR and JMC for years was commercial feature of java, but commenter doesn't complain about "proprietary" Oracle)
I am definitely not into language details, but I feel like better java could mean better kotlin. java is not only the language, but to some degree also the jvm: afaik kotlin compiler is translating some constructs into equivalent jvm bytecodes, if by developing java those constructs become first class citizens in the jvm, then kotlin compiler will be faster. from a user point of view, you won’t see a new feature, but the feature will work ‘better’. the main problem could be the other way around, but java development is handled through jeps so it is possible kotlin will get inspired by those jeps and implement them the kotlin way before they will find their way in java and then kotlin can iterate by leveraging what java introduced.
surely the closer the 2 languages becomes and should it end up being only a difference in syntax, then there will be some redundancy. kotlin supports multiplatform, or wants to, but I am personally not yet convinced (I am mostly BE, but saw the back and forth between native, then webview, then native again, and to some degree I would pick webviews there, ‘portable’ between different platforms - don’t quote me, never went beyond pet projects outside BE development0
Right now majority of kotlin indeed targeting JVM (or ART), but in 5-6 years it can be LLVM and JS more popular than JVM target, who knows 🙂