Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Exploring the .class Side of Kotlin (Part 2)

DZone's Guide to

Exploring the .class Side of Kotlin (Part 2)

See how this tool can help you compare your Java and Kotlin code side-by-side for performance evaluation and interoperability.

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

Recap: from Exploring the .class side of Kotlin, while working with Kotlin, I was missing the means to visualize my Kotlin code as the equivalent Java code next to its bytecode representation in a convenient way (less than three 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 a 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 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.

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, what the class size would be 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 out the video.

Happy coding!

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:
mobile ,kotlin ,mobile app development ,android

Published at DZone with permission of Boris Farber, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}