Migration of Java Code to Kotlin for Enhanced Code Consistency and Maintainability #5928
Comments
|
I agree wholeheartedly with your points, and we started the process several years ago. It will take a long time and quite a lot of work, however, as it involves rewriting large portions of the app. Would you be interested in working on this, @Saifuddin53 ? |
|
Yes @misaochan @nicolas-raoul, I'm interested in contributing to this migration process. I plan to start with the utility/helper classes, as they are more isolated and easier to migrate. After completing that, I’ll adopt a module-wise approach, focusing on one module at a time to ensure smooth transitions and minimal disruptions. Alternatively, if needed, I can prioritize specific areas, such as the data layer or UI components. Since this involves a large amount of work, anyone interested in joining the migration process is more than welcome to collaborate. It would be great to share the workload and move faster while ensuring high-quality results. |
|
That sounds great, thank you very much. :) I'll assign you to this @Saifuddin53 , but if anyone else is interested, please feel free to chime in. Unlike other issues, I think it should be fine for multiple people to work on this one, as it is a huge task. We can probably add a checklist later to track the PRs as they come in. |
|
Thank you so much for assigning me to this, @misaochan Also, for anyone who’d like to join this migration effort:
This approach will help us stay coordinated and avoid overlaps. |
|
Working on Bookmark module & Achievement Module |
|
I guess its better to migrate a class by class to java to kotlin rather than a module by module. isn't it? Focusing more on refactoring our previous java code too as things in kotlin gives us lot of advantage to null pointer and fixing our lint issues since its a whole rewrite. What's your take? |
Of course, that's a valid point, @neeldoshii. You can also take that approach too, as mentioned earlier. A hybrid approach might work well here. However, there are also benefits to the module-by-module approach, it allows us to complete logical chunks of the application which can be tested and reviewed in isolation. |
Chris, read back up this issue, and see all of the merges and people posting to claim packages? It already is happening; the grass-roots / self-organizing movement is doing great. Make a cup of tea, sit back and maybe have some fun - visualize the updates to the project with a tool like Gource 😄 |
|
Thanks, Paul; i've already moved on. The 500 bugs will sort themselves, even the ones that are 10 years old. I'll continue as a Commons user, and leave organising to those best able to do it. Chris |
|
Quick check on status - searching for a count of Java files remaining in packages -
Great work all! Let's keep it going! |
|
@nicolas-raoul Can i also work on this issue so that work get completed fastly |
|
Yes @Sujal-Gupta-SG, feel free to go ahead and start working on it. Choose a package or file you'd like to work on, create an issue for it, and begin your work. Once you're done, submit a pull request. 🙂 |
|
I am migrating contribution folder if anyone is doing already let me know |
|
Based on what is currently on the find . -name \*.java >> remaining.txt NearbyExploreBookmarksMediaTop Level |
What is the user problem or growth opportunity you want to see solved?
The current codebase consists of a mix of Java and Kotlin, which introduces inconsistencies and can make the code harder to maintain and extend. Migrating fully to Kotlin would streamline the code, reduce verbosity, and provide a more cohesive developer experience. This transition would also open up future opportunities to leverage Kotlin Multiplatform (KMP), facilitating easier expansion to iOS if desired.
How do you know that this problem exists today? Why is this important?
Android development is increasingly Kotlin-centric, as it’s the recommended language with strong support for modern Android features, readability, and efficiency improvements. Having a consistent codebase fully in Kotlin will improve maintainability and simplify onboarding.
Who will benefit from it?
Anything else you would like to add?
Once the migration to Kotlin is complete, further modernization could include adopting Jetpack Compose for the UI layer, reducing XML dependency, and simplifying the UI structure. This approach would prepare the project for KMP, creating a strong foundation for potential iOS app development in the future.
The text was updated successfully, but these errors were encountered: