We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Shrinking in the Age of Kotlin

Formale Metadaten

Titel
Shrinking in the Age of Kotlin
Serientitel
Anzahl der Teile
542
Autor
Mitwirkende
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Java is now more than 25 years old and throughout the Age of Java there has been many tools for shrinking, optimizing and obfuscating Java bytecode. This was and is especially important for mobile devices, which have certain resource constraints, from the early J2ME devices to today's Android devices. Today, in the Age of Kotlin, shrinking is more relevant than ever and not just for mobile applications. As well as mobile Android applications, desktop & server applications are also ever growing in size; for example Compose for Desktop typically generates large application packages. JetBrains has recently integrated ProGuard into the Compose for Desktop Gradle plugin to tackle this issue. But what has changed and how does Kotlin affect shrinkers like ProGuard (which is 20 years old and originally created to process Java compiler produced bytecode)? How does ProGuard shrink classes produced by the Kotlin compiler? The Kotlin compiler just produces Java bytecode anyway, so nothing changes? The talk will take a look at ProGuard under the hood and what's required to process Kotlin apps & libraries. In particular, there will be a deep dive into Kotlin metadata and how ProGuard (via the ProGuardCORE library) makes use of JetBrains' kotlinx.metadata library to read & write the metadata.