Kotlin Kuestions for adoption

KotlinKuestions.md

Kotlin Kuestions

What are the expected technical benefits?

• "It’s pragmatic and concise, and makes coding a satisfying and efficient experience."

• Java is an old and mature language. It brings a lot of functionality and ability, but it also brings a lot of technical debt and anti-patterns that have only become apparent after decades of usage. Kotlin has taken note of these shortcomings and included fixes and mitigations of them in the design of the language. These design decisions have a profound, net-positive effect on application code that is produced. These effects make the code more terse, and much more expressive about the developers intention and its actual functionality. Some examples of these improvements are:

  • Immutability
  • Reassignments
  • Null-safety
  • No Checked Exceptions
  • Readability of code.
    • Removal of a lot of boilerplate
    • More expressive
    • String interpolation

• For more detailed discussions of the benefits, see:

  • Why you should totally switch to Kotlin
  • A Kotlin Wishlist for Java
  • The best features of Kotlin!

What is the expected impact if we learn Kotlin wasn't a good choice?

• If we decide that Kotlin was not a good choice, the expected impact would be minimal. This concern has been discussed and planned for since the beginning of this project.

• Kotlin has 100% interoperability with Java and compiles down to JVM bytecode. This means that if we must remove Kotlin from our codebase immediately for whatever reason, this bytecode can be decompiled back into java and put back into the codebase with complete parity of behavior.

  • IntelliJ has built in support for Decompiling Kotlin to Java

• Otherwise, if we decide to remove Kotlin over time then re-implementing the Kotlin code into Java is feasible, and less workload than re-writing from scratch from a non-JVM language.

• We have intentionally been limiting the implementation of Kotlin one module, in order to minimize its impact on the current Java codebase, so we have the option, like we have done with other technologies we have stopped using, to leave Kotlin code isolated but untouched so we can remove it at our leisure in the future.

Are there any known technical hurdles? Do you have a plan to address them?

• No known technical hurdles.

What impact does this have on our build process?

• Compiling down to Java bytecode results in no impact to the existing build process.

Does the Kotlin code exercise the same checks as the rest of the code? (i.e. security, api limits, etc...)

• Yes, it functions alongside all Java code and is integrated into Spring seamlessly.

Is there anything that needs to be re-implemented, like CSRF validation?

• No re-implementation needed, all of our Java code can be utilized by Kotlin, and vice-versa

How is the team tying it to our existing tooling

• Builds - No changes needed to support. Maven plugins in the project module handle compiling.
• SonarQube - Plugin needed
• IDE - Plugins available for all the IDEs we know are in use in Engineering
• REST Tests - Rest endpoints built in Kotlin are indistinguishable from other endpoints, so no changes here
• Security Scans: These are done via 3rd party, so impossible to know for sure, but if it is done via pom scanning or by scanning the outputted jars then there should be no difference between Kotlin and Java

What steps is the team taking to prevent a tech knowledge silo? i.e. can everyone on the project team develop in, troubleshoot, and work in Kotlin? Can we expand that to the broader engineering team or backend devs?

• Pairing, Mobbing and Swarming are our main tools to prevent siloing.
  • All of the team’s backend developers are easily able to be effective using Kotlin
• Time can be set aside (office hours, 1:1 help) by those comfortable with Kotlin to help train other developers.
• Kotlinlang.org provides a detailed set of Koans to introduce people to the language
• Many resources online:
  • Kotlin Slack community
  • Fast growing body of knowledge on Stack Overflow
  • Kotlin forums
  • Extensive, well written documentation
• We don’t believe that any prerequisite training (i.e. workshops) are needed before a developer/team can start working in Kotlin, although they are always valuable (as with any technology)

Is the tech compatible with upcoming changes (Java 11)?

• Kotlin will be compatible with Java 11, but it’s unknown when it will be able to target Java 11 for bytecode. Currently compiles to 1.8
• Other tech changes:
  • Major libraries like Spring and Hibernate are increasingly supporting Kotlin, so future upgrades will make it even better!
  • Java compatibility means that it works with existing systems and there shouldn’t be any significant risks from upcoming tech changes that we wouldn’t have to deal with in Java.

Does Kotlin introduce any dangerous open source library dependencies (GPL3)?

• Kotlin is licensed with the Apache 2.0 license
• Other relevant licenses are listed here.
• Most are MIT, Apache 2.0 or BSD
• None are GPL3

How mature is this tech? Support model, use in other companies, etc?

• Kotlin has moved from Assess, through Trial and was moved to Adopt in ThoughtWorks’ Technology Radar within the past year.
• Google has selected Kotlin as the preferred language to write Android applications in.
• “JetBrains Account, the system responsible for the entire license sales and validation process at JetBrains, is written in 100% Kotlin and has been running in production since 2015 with no major issues.”

Will our customer-hosted customers need to learn this?

• No. Delivered war is identical to java.
• Anyone developing Velocity reports will be able to use Kotlin methods as if they were Java methods.

Is there a cost? What is the license model? What about distribution requirements (again for self-hosted)?

• No financial cost
• “Kotlin is free, has been free and will remain free. It is developed under the Apache 2.0 license and the source code is available on GitHub.”
• No distribution requirements

Any security concerns?

• None we’re currently aware of

How does this affect hiring?

• We feel that the adoption of Kotlin is a clear indicator that we as a company are exploring new innovations in a space that is very exciting for a lot of Developers and Software Engineers. This will have a positive effect when trying to attract new, forward thinking talent to our Engineering department.
• There is no reason to think we will need to change our current hiring practices specifically to target Kotlin developers.

Debugging: any concerns with debugging since some code may be generated by Kotlin?

• Stack traces and debugging breakpoints look and function the same as they do in Java. Streams with lambdas will actually present a little cleaner.
• For profiling, JProfiler added support for Kotlin source navigation in JProfiler 10, released over a year ago.

How is unit testing impacted since Kotlin classes are final by default and hard to mock?

• The spring plugin for the Kotlin compiler makes bean classes non-final, so they are easily mocked
• Other classes can be instantiated directly, which is much easier with Kotlin's default constructor arguments, reducing our reliance on mocks.

Plan for Kotlin going forward

• Short term Kotlin will be restricted to the one team and module. This is easily enforced, since each module that has Kotlin requires the kotlin-maven-plugin, so we can make sure it isn’t used anywhere else.
  • This will allow a single team to continue evaluating Kotlin through the full lifecycle of a new feature, which should uncover whether or not there are any major issues with full Kotlin adoption.
• Long term:
  • We have two options
    • Getting full sign-off and opening up Kotlin for anyone to use inside the application
    • Instituting a lightweight process per module/tool we want to use Kotlin in to evaluate whether adding Kotlin is appropriate
  • Option 2 is heavier, and likely to slow Kotlin adoption, but more conservative if we feel there is still a risk to using Kotlin.