Exploring the .class side of Kotlin — Part 2

Recap: from Exploring the .class side of Kotlin, while working with Kotlin I was missing a mean to visualise my Kotlin code as the equivalent Java code next to its bytecode representation in a convenient way (less than 3 mouse clicks), mostly for performance evaluation and Java Kotlin interoperability. I wrote a small tool, CS Bytecode Viewer that opens a class file and shows its Java and bytecode representation.

I tracked my Kotlin flow usage since then and would like to present the key learnings.

My flow for Kotlin is writing code either in Android Studio (for Android) or IntelliJ IDEA (for Desktop). I keep a CS Bytecode Viewer instance open as a separate window with a relevant class file opened. Each time I change the code and the class is recompiled (usually automatically) the CS Bytecode Viewer tracks the file modification and shows the updated version, so I can inspect the changes.

I spend most of the time looking at the Java code (close to 95% to be precise, yes we love numbers). Once I see my Kotlin code as the equivalent Java, it usually answers the question I was looking for. The remaining 5% of the time, I am checking for low level things like enums with switch cases, and how koltinc compiled them down to a class file — turns out, it is actually pretty efficient.

I got few requests to sync the scrolling between the Java and ASM parts, however it is hard to comprehend all the class internals. Both Java and ASM present the same data but on a different levels of abstraction, putting both views side by side created a lot of visual (albeit interesting ;)) noise.

The best solution is to put Java and ASM in separate tabs, and look at them separately, while trying to solve different problems.

And if we are in the flow from Java to ASM the next level is to look at the binary directly. To be honest, at the beginning I added the hex pane just out of curiosity, as I always wanted to implement one :). It was a super useful learning experience, that included Kotlin with low level Swing and byte manipulations.

Turns out the hex view is useful for analysing the actual size (yes in bytes) of a class. Say you have a lambda expression in your Kotlin code, in how many classes your lambda is compiled to, what would be the class size if you were to write your code in Java and why, come on go and do it on your own code, I will wait here.

All in all I enjoyed working that way, and this is part of my flow when I work with Kotlin. Victoria Gonda and I are going to give a talk about all of this and more in the upcoming KotlinConf conference next month. If you can’t come in person check the video.

Happy coding !