https://kotlinlang.org logo
Join Slack
Powered by
# j2k
  • m

    Michael Paus

    06/26/2024, 8:39 AM
    I am wondering why J2K is not getting some more love. Especially in the light of Kotlin multiplatform it could be the essentiel tool to help fill the gap of missing multiplatform libraries. In practice however this is hindered by the fact that J2K still has no clear strategy and way too many bugs. I for myself have just given up on converting a larger Java library to Kotlin because due to the above mentioned problems it would just be too much work. Very often the generated code does not even compile or is not Java compatible anymore so that you cannot run an existing Java test suite against the generated Kotlin code. Sometimes, and that’s the worst case, the code does compile but has different semantics and produces wrong results which you can only catch with a very good test suite and when you report such bugs it takes years until they are take care of or not at all. What do you think? I think J2K is important enough so that these things at least deserve some discussion.
    a
    • 2
    • 6
  • m

    Michael Paus

    08/14/2024, 7:30 AM
    A simple question. Does J2K already support the new JSpecify annotations?
    a
    • 2
    • 1
  • a

    Anton Yalyshev [JB]

    08/16/2024, 12:21 PM
    Hey folks 👋 This channel has been set up by a group of engineers from Meta, Uber, Google, and JetBrains that are working on Java to Kotlin conversion infrastructure in their companies. We came together at KotlinConf ’24 and showcased our methods for large-scale code conversion, the tech we’re using together and common challenges we’ve encountered. We hope that the experiences and tools we share will be useful for other teams in the Kotlin community, and that the discussion around automatic J2K conversion for large-scale codebases will grow. Briefly speaking, the most common way of automating conversion of large amounts of code is to convert gradually via a pipeline that can be automated or run interactively with this general structure: 1. Mutate module’s build files to support Kotlin files 2. Prepare Java code for conversion: minor modifications that make the code more understandable for J2K (e.g. adding nullability annotations) 3. Run IntelliJ J2K converter in headless mode on the selected file(s) 4. Postprocess converted code: polish converted Kotlin code to make it more idiomatic (e.g. renaming properties to avoid hungarian notation; updating external references to getters-turned-properties that J2K missed) 5. Prepare patch/commit that can be applied to the project (ideally recognizing the conversion as a file move/rename to preserve source control history) 6. Use CI and human review to guarantee accuracy of final code - take the gaps as datapoints informing additional pre/post processing rules Other notable ways of automating conversion: 1. The Google Workspace team has converted millions of lines of code at once as a step in their build process. The resulting code isn’t idiomatic (and isn’t checked in to their repo for developers to read/edit), but it allows them to leverage KMP 2. Other teams at Google are using a custom alternative to J2K which avoids the need for changes outside the code being converted by preserving getters, etc. 3. Engineers at Uber are exploring using a dataset of converted code java to koltin code to inform LLM models and agentic systems to facilitate the faster build-out of new pre/post processing rules.
    👍 2
    ❤️ 1
    m
    • 2
    • 1
  • a

    Anton Yalyshev [JB]

    08/16/2024, 12:21 PM
    Things we have done recently: • 2024.2 IntelliJ J2K Converter added extension points to make it more convenient to programmatically add custom steps to its conversion pipeline. • Meta team has already published some post-processing rules that are not dependent on IntelliJ. (If other folks are interested in contributing, they can move those steps to a more collaboration-friendly repository) Also, engineers from Meta are planning to share a plugin that leverages the extension points added in the 2024.2 J2K Converter that include: • Preprocessing rules (e.g. adding nullable annotations) • Postprocessing rules: fixing some code smells and improving code safety of generated Kotlin code If you have in your project some automated procedures of Java to Kotlin Conversions, share your approach and let’s exchange our experience and findings. Or if you find things described above useful for your project - don’t hesitate asking any questions!
    👍 3
  • a

    Anton Yalyshev [JB]

    08/16/2024, 12:25 PM
    set the channel description: This channel is dedicated to the practices of converting Java code to Kotlin in large projects. Processes, rules, infrastructures, problems and challenges. Let’s share our experiences and results! This will help find new ideas and solutions
  • p

    Petter Måhlén

    11/19/2024, 10:15 AM
    Hi, I'm interested in trying out automated java-to-kotlin conversions in our codebase (a ~5 MLOC android codebase built with Bazel, where we've still got 450kLOC of Java code). I'm only just starting to look at it, and it's not super easy to see how to do things using the j2k plugin. For instance, what's a reasonable way to run it in headless mode? It seems like I need a JavaToKotlinConverter instance, but I'm not sure which one would be best to pick, and I'm also not sure how to feed it with PsiJavaFiles. Any pointers would be most welcome!
  • p

    Petter Måhlén

    11/19/2024, 10:19 AM
    On another note, the main reason I'm looking into this isn't really to be able to finish our j2k migration, but actually to learn more about large-scale migrations and to try to find patterns for them and how we (Spotify) can be more efficient at doing them. This felt like a complex example where others have made a head start already, so potential good way to learn without being too overwhelming. But we've got a bunch of other migrations that have been in progress and remain unfinished years after they started - things like changing the best practices for writing UI, or using coroutines instead of Rx, etc., etc. Is this is a challenge that others in this channel are also interested in? Do you have similar problems in your codebases?
    👀 1
    👍 1
    e
    • 2
    • 4
  • a

    alostpacket

    12/19/2024, 12:54 AM
    👋 Not sure if there are any Meta engineers in here but I just read this great article: https://engineering.fb.com/2024/12/18/android/translating-java-to-kotlin-at-scale/ really enjoyed reading this and I had a question about a line in there.
    Compiling Kotlin is slower than compiling Java, but compiling both together is the slowest of all.
    This matches what I have read in the past but I haven't been able to find any numbers. Do y'all have any numbers by any chance? Or maybe someone else in here does? Anything is helpful, looking for data to back up advocating for getting to 100% Kotlin too. thank you frog
    👋 1
    e
    s
    t
    • 4
    • 6
  • a

    Andrew Vasilyev

    03/12/2025, 2:45 PM
    Hi, folks! I want to take a look at the problem in my spare time. Feel free to share any input or requirements if you have any.
    ❤️ 1
    👍 1
    a
    • 2
    • 1