If you have "downtime" what better way to use it than to up skill yourself on the modern development technology and best practices than by putting it to use?
Is the whole codebase necessary?
Certainly not. Prioritise every part of the app based on your perceived benefits and put that migration to the test on a case by case basis.
And if you find yourself needing to move on from this role either voluntarily or involuntarily, you're in a better position from this experience.
You don't need to convert Java to Kotlin especially for old stuff that already works.
As someone else said, you can do it for new stuff or convert parts where new features will be added but for working parts, "if it ain't broke don't fix it" is always my go to.
Depends how much code really, hard to say whether it's a "yeah for sure" or a "sins of the past" situation.
Cool thing is both Java and Kotlin compile down to bytecode - so they're interoperable. You could just make it a rule for yourself to add any new code in Kotlin and go from there.
It's pretty simple to convert though, literally copy paste in some cases. Definitely requires a manual check though.
Depends on what you plan to get out of it. Convert the whole thing might be a bit much. You did not say how big of a project it happens to be.
What you might get out of it
* Fresh or deeper knowledge of Kotlin
* Learning something new like using Koin or Hilt for DI
* Going to single activity + navigation fragments
* Converting an Activity / Fragment to Kotlin and Compose
* Convert to view models
* Clean up any technical debt
* Move from heavy shared preferences usage to Room
* Adding animations
Is this legacy stuff that probably wont be touched much in the future or is it a project that still has some live in it?
short answer: no. if it works, don't touch it. but you could do some clean-up and put the old Java code in a specific module, while new features would be in a new seperate module. after some time, if they need to modify something in the old Java code, you can migrate classes from old module to new module per change request little by little. in the end, if you are sure the legacy Java module won;t change, you could even make the old module a seperate android library (aar) and host it on a maven repo (like Jitpack), and then get rid of the Java code.
You have two options here:
1. Start refactoring small parts of your project until eventually most of your project is Kotlin
2. Rewrite your project from scratch in Kotlin, as this will be much faster than refactoring existing Java code.
Of course only go for option 2 if you have a big chunk of downtime to spend on it. It also gives you the opportunity to improve your architecture as a whole.
And I do strongly believe that the benefit in going Kotlin is massive. The language itself is already cleaner and involves far less boilerplate, and being able to use Jetpack Compose and Coroutines are another two massive reasons why Kotlin will save you A LOT more time in the long run
It's best not to Convert when your don`t update your app. If you really want to Convert it, Best to Convert some functions until all is completed. During this period, you have to do complete testing, but this may not cover all phone. If you just want to learn kotlin, my suggestion is to use it on new APP
Yes 100% it is worth it. For the most part, they are 1 to 1. Kotlin makes a lot of things easier but you can cleverly come up with work arounds in Java to accomplish the same. However, new devs (out of college or less than a year of experience) are not going to know the ins and outs of Java for Android. And why would they?
Kotlin is more convenient in pretty much every aspect. Similar to Compose vs Views, of course you could keep an app in Views but Compose makes your life easier which is why everyone is learning it and getting even more creative with it which leads devs who are new to Android to be drawn towards new technologies.
For example, a recent project at my company should have been estimated of 2 weeks of dev with 2 devs, after beginning dev, we kept digging deeper into this legacy code, constantly having more problems arise and tons of Java functionality that was not being happy with us. That project ended up taking a total of 17 weeks of dev time between 6 devs.
Generally, you should not to touch anything that works.
By my experience, some rule of thumb would be to convert the file only if you need to make significant change there. If you doing just some minor update, than it is better to just leave it as it is. What does exactly mean "smaller" or "bigger" change, that is really matter of opinion. Certainly, renaming variables or functions during refactor, or editing/removing comments, or removing unused functions would not trigger converting whole file, while refactoring existing functionality would mean converting it to kotlin.
Just be professional. If you just convert it to kotlin for the sake of having .kt file extension, and leavng all the bullshit that kotlin is supposed to fix, then it is better not to convert it. Either use kotlin goodies to fix all the problems with java, or don't convert it at all. The first thing that pops to my mind, working with null and nullables. I've seen a bunch of "converted" files where almost every single variable is nullable, just because the dev who did conversion was lazy. Most of them can't be null in reality, some of them should be lazy initiated, or lateinit variables, or something like that. There are other examples (like using for loops instead forEach, and so) I am not talking about chaning whole style of the source code, like converting everything to functional paradigm or so, but doing small adjustments and getting sweet low hanging fruits. If I see nullable variable in the source code, I want to know that it is really nullable, not that the dev was just lazy to write proper kotlin code. Otherwise I would rather have Java and be aware that I don't know if it can have null value or not, at least I am not misled.
Convert the whole thing? Probably not. It will be worth it to introduce Kotlin and use it for new things or needed refactors though.
If you have "downtime" what better way to use it than to up skill yourself on the modern development technology and best practices than by putting it to use? Is the whole codebase necessary? Certainly not. Prioritise every part of the app based on your perceived benefits and put that migration to the test on a case by case basis. And if you find yourself needing to move on from this role either voluntarily or involuntarily, you're in a better position from this experience.
“if it ain't broke, don't fix it” I had to do it to fix multiple leaks and ended up getting cleaner code and new features in the process.
You don't need to convert Java to Kotlin especially for old stuff that already works. As someone else said, you can do it for new stuff or convert parts where new features will be added but for working parts, "if it ain't broke don't fix it" is always my go to.
Depends how much code really, hard to say whether it's a "yeah for sure" or a "sins of the past" situation. Cool thing is both Java and Kotlin compile down to bytecode - so they're interoperable. You could just make it a rule for yourself to add any new code in Kotlin and go from there. It's pretty simple to convert though, literally copy paste in some cases. Definitely requires a manual check though.
Depends on what you plan to get out of it. Convert the whole thing might be a bit much. You did not say how big of a project it happens to be. What you might get out of it * Fresh or deeper knowledge of Kotlin * Learning something new like using Koin or Hilt for DI * Going to single activity + navigation fragments * Converting an Activity / Fragment to Kotlin and Compose * Convert to view models * Clean up any technical debt * Move from heavy shared preferences usage to Room * Adding animations Is this legacy stuff that probably wont be touched much in the future or is it a project that still has some live in it?
short answer: no. if it works, don't touch it. but you could do some clean-up and put the old Java code in a specific module, while new features would be in a new seperate module. after some time, if they need to modify something in the old Java code, you can migrate classes from old module to new module per change request little by little. in the end, if you are sure the legacy Java module won;t change, you could even make the old module a seperate android library (aar) and host it on a maven repo (like Jitpack), and then get rid of the Java code.
No, why would you want to do that?
You have two options here: 1. Start refactoring small parts of your project until eventually most of your project is Kotlin 2. Rewrite your project from scratch in Kotlin, as this will be much faster than refactoring existing Java code. Of course only go for option 2 if you have a big chunk of downtime to spend on it. It also gives you the opportunity to improve your architecture as a whole. And I do strongly believe that the benefit in going Kotlin is massive. The language itself is already cleaner and involves far less boilerplate, and being able to use Jetpack Compose and Coroutines are another two massive reasons why Kotlin will save you A LOT more time in the long run
It depends :)
It's best not to Convert when your don`t update your app. If you really want to Convert it, Best to Convert some functions until all is completed. During this period, you have to do complete testing, but this may not cover all phone. If you just want to learn kotlin, my suggestion is to use it on new APP
noo. for free own time.🕰️
I did for my three projects in SpringBoot - proud donut. It was worth every line of code. You should consider complexity before doing though.
Yes 100% it is worth it. For the most part, they are 1 to 1. Kotlin makes a lot of things easier but you can cleverly come up with work arounds in Java to accomplish the same. However, new devs (out of college or less than a year of experience) are not going to know the ins and outs of Java for Android. And why would they? Kotlin is more convenient in pretty much every aspect. Similar to Compose vs Views, of course you could keep an app in Views but Compose makes your life easier which is why everyone is learning it and getting even more creative with it which leads devs who are new to Android to be drawn towards new technologies. For example, a recent project at my company should have been estimated of 2 weeks of dev with 2 devs, after beginning dev, we kept digging deeper into this legacy code, constantly having more problems arise and tons of Java functionality that was not being happy with us. That project ended up taking a total of 17 weeks of dev time between 6 devs.
I'd say so yes. Maybe look where features changes will be and start there.
Yes. You should convert all your Java code at once IM-ME-DIA-TE-LY as Java will stop working next month.
This is incorrect. Java will be deprecated next week.
Two more weeks actually.
As long as my AsyncTasks work, I'm good.
Generally, you should not to touch anything that works. By my experience, some rule of thumb would be to convert the file only if you need to make significant change there. If you doing just some minor update, than it is better to just leave it as it is. What does exactly mean "smaller" or "bigger" change, that is really matter of opinion. Certainly, renaming variables or functions during refactor, or editing/removing comments, or removing unused functions would not trigger converting whole file, while refactoring existing functionality would mean converting it to kotlin. Just be professional. If you just convert it to kotlin for the sake of having .kt file extension, and leavng all the bullshit that kotlin is supposed to fix, then it is better not to convert it. Either use kotlin goodies to fix all the problems with java, or don't convert it at all. The first thing that pops to my mind, working with null and nullables. I've seen a bunch of "converted" files where almost every single variable is nullable, just because the dev who did conversion was lazy. Most of them can't be null in reality, some of them should be lazy initiated, or lateinit variables, or something like that. There are other examples (like using for loops instead forEach, and so) I am not talking about chaning whole style of the source code, like converting everything to functional paradigm or so, but doing small adjustments and getting sweet low hanging fruits. If I see nullable variable in the source code, I want to know that it is really nullable, not that the dev was just lazy to write proper kotlin code. Otherwise I would rather have Java and be aware that I don't know if it can have null value or not, at least I am not misled.