Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Adopting Kotlin, Or: How we learned to stopped ...

Adopting Kotlin, Or: How we learned to stopped worrying and love the null

A case study presented by Duncan McGregor & Nat Pryce at SPA 2017

Nat Pryce

June 27, 2017
Tweet

More Decks by Nat Pryce

Other Decks in Programming

Transcript

  1. Adopting Kotlin Or: How we learned to stopped worrying and

    love the null Duncan McGregor & Nat Pryce
  2. What is Scala? • A statically-typed OO/functional hybrid language running

    on the JVM • A hell of a compiler • An impressive runtime • Still evolving Kotlin?
  3. @

  4. What were we building at Springer Nature? •Server-side JVM webapps,

    hosted on Undertow •Nat - 6 devs, Postgres, RabbitMQ •Duncan - 4 devs, Elastic Search and Postgres •Algorithmically uninteresting •TDD, mostly XP •IntelliJ, Gradle, Git •Springer Nature’s own CD pipeline to Cloud Foundry
  5. Why did we adopt Kotlin? Because •we like / needed

    to run on the JVM •it’s so hard to do simple things in Java •we’re too old to cope with dynamic languages •we value excellent tool support •everything else was worse
  6. Why Might You Migrate? •Productivity • FP benefits in algorithm

    design • Immutable throughput for multi-core • Expressiveness • The Python Paradox
  7. Coming up... What we did Overenthusiasm Culture Shock Gradually converting

    a Java application to Kotlin without slowing delivery. We went too far so that you don't have to. Kotlin is a foreign country; they do things differently there.
  8. How did we migrate? •Build in both Java and •New

    classes in Scala •Migrate existing classes case-by-case ▪ “Convert File to Kotlin” ▪ Move to functional style ▪ Embrace null ▪ Adopt Kotlin idioms This is also a good model for learning Scala Kotlin Kotlin Kotlin
  9. Code layout and organisation The Kotlin style guide is not

    very extensive It seems trivial, but inconsistent conventions became annoying • Code layout • Code organisation • Visibility modifiers Each project developed its own conventions … eventually. They were all slightly different.
  10. It took us time to accept using null data class

    SubmissionDraft( override val id: DraftId, override val submissionStatus: SubmissionStatus, override val createdTimestamp: Instant, override val submittedTimestamp: Instant? = null, override val submissionId: SubmissionId?, override val decisions: UserDecisions )
  11. Extension functions on nullable types "Elvis has left the building!"

    This can be null in an extension method of a nullable type! fun String?.orEmpty() = if (this == null) "" else this fun <T> List<T>?.orEmpty() = this ?: emptyList() Beware: toString is an extension method of a nullable type! val maybeCount: Int? = … maybeCount?.toString() // returns null or the count maybeCount.toString() // returns "null" or the count The type checker won't help: String is a subtype of String? Impossible to spot the difference in test diagnostics!
  12. Exceptions are not type checked! "Failure is not an option!"

    sealed class Result<out T, out ERR: Any > data class Failure<out ERR: Any>( val value: ERR) : Result<Nothing,ERR>() data class Success<out T>(val value: T) : Result<T, Nothing>() inline fun <T, U> Result<T>.map(f: (T) -> U): Result<U> = ... inline fun <T, U> Result<T>.flatMap(f: ( T) -> Result<U>): Result<U> = ... inline fun <T> Result<T>.forEach(f: (T) -> Unit): Unit = ... inline fun <T> Result<T>.orElse(f: (ErrorCode) -> T) = ... inline fun <T> T?.asResultOr(errorCodeFn: () -> ErrorCode): Result< T> = ... ... etc. Use the same method names as Kotlin's collections: "map", "flatMap", "filter", ...? Or something domain-specific? ?
  13. Exceptions are not type checked! Technical error? Further action? Catch

    as close as possible to failing call. Return an error code in a Result.failure Translate to HTTP response in the web layer Let the exception propagate – the web layer will send a 500 response Yes No Yes No
  14. Enforced by fuzz testing @Test fun `reports all parse errors

    with a JSON Pointer`() { val validJson = exampleAmendmentRequest.toJson() val mutants = random.mutants( defaultJsonMutagens().forJackson(), 500, validJson) mutants.forEach { mutantJson -> val result = format.parseJson(mutantJson) // no exception thrown if (result is Failure) assertThat(result.value, isA<InvalidJson>( has(InvalidJson::pointer, present()))) } } https://github.com/npryce/snodge
  15. Result<T> instead of exceptions fun sendToEjp(draft: SubmissionDraft): Result<SubmissionId> = journals.getByPCode(draft.pCode)

    .flatMap { journal -> journal.ejpJournalId .asResultOr { PeerReviewSystemNotSupported(ejp, draft.pCode) } .flatMap { ejpJournalId -> payloadConverter.convertForCreate(draft) .flatMap { requestJson -> val uri = EjpUrlRoutes.create.path(ejpJournalId) sendCreate(uri, payload) .flatMap { responseJson -> responseJson.toSubmissionId() } } } } Type safe, but...
  16. Accept early returns in functional code inline fun <T> Result<T>.onFailure(handler:

    (Failure) -> Nothing): T = when (this) { is Failure -> handler( this) is Success -> value } fun create(draft: SubmissionDraft): Result<EjpSubmissionId> { val journal = journals.getByPCode(draft. pCode) ?: return Failure(JournalNotFound(draft. pCode)) val journalId = journal. ejpJournalId ?: return Failure(PeerReviewSystemMisconfiguration()) val ejpPayload = ejpPayloadConverter.convertForCreate(draft) .onFailure { return it } val uri = EjpUrlRoutes. createPath.path(journalId) val responseJson = sendCreate(uri, payload) .onFailure { return it } return responseJson.toSubmissionId() }
  17. So Far So Good •At this point you just have

    a better Java • More consistent • Default immutability • Better collections • Less noisy • More bang per line of code • Fast
  18. Except •The build is much slower •Tool support is worse

    •Debugging is harder •Error messages are sometimes cryptic •Scala runtime source is opaque •Scala is evolving
  19. The Next Step •Scala tools for making code more expressive

    • Mixin traits • Pattern matching • Implicit conversions / parameters • Operator overloading • AST Macros • Compiler plugins
  20. Extension functions (as usually described) Additional methods defined on types

    we don’t own. Before val name = mandatoryChild(node, "name") fun mandatoryChild(node: JsonNode, name: String): JsonNode = node.get(name) ?: throw MissingPropertyException(name) After val name = node.mandatoryChild(“name”) fun JsonNode.mandatoryChild(name: String): JsonNode = get(name) ?: throw MissingPropertyException(name)
  21. Class cluttered with application functionality class Address( … ) {

    fun isInCountry(county: Country) = … fun isFreeDelivery() = … fun somethingTheUserInterfaceNeeds() = … fun somethingTheDatabaseNeeds() = … } Or application functionality in functions enable(checkbox, isFreeDelivery(preferredAddress(customer))) We extend our own types
  22. Local extension functions for local logic Fundamental abstraction class Address(

    … ) { fun isInCountry( … ) } Logic specific to a part of the business domain fun Address.isFreeDelivery() = UI Module fun Address.somethingTheUserInterfaceNeeds() = … Persistence Module fun Address.somethingTheDatabaseNeeds() = …
  23. Extension functions allow concise names Nested functions can be verbose

    and hard to read checkbox.enabled = addressIsFreeDelivery(customerPreferredAddress(customer)) Extension functions chain nicely checkbox.enabled = customer.preferredAddress.isFreeDelivery (And make it much easier to deal with null references)
  24. Descriptive names instead of direct calls to copy(). Before val

    newState = submission.copy(files=submission.files + newFile) After val newState = submission.plusFile(newFile) ... fun Submission.withNoFiles() = copy(files=emptyList()) fun Submission.withFile(f: File) = copy(files=listOf(f)) fun Submission.plusFile(f: File) = copy(files=files + f) Extension functions of data classes Use a common naming convention across the code base. E.g. "withXxx" replaces, "plusXxx" adds, "minusXxx" removes.
  25. Parameterise, rather than extend Before val rootUri = config.getURI("server") val

    accessToken = config.getString("accessToken") val timeout = config.getLong("timeout") After val rootUri = config.get(uri, "server") val accessToken = config.get(string, "accessToken") val timeout = config.get(long, "timeout") object uri : Parser<URI> { override fun parse(s: String): URI? = try { URI(s) } catch (e: URISyntaxException) { null } override val name = "URI" }
  26. Extension functions can be instance methods! A data type that

    will be extended data class Address(..., val postCode: PostCode) Extension function used in a method of a class and defined in that class class PlaceOrder( private val delivery: DeliveryApiClient ): UserAction<Order> { override fun invoke(order: Order) { if (order.deliveryAddress.allowsFreeDelivery()) ... ... } private fun Address.allowsFreeDelivery() = delivery.methodsFor(postCode).find { it.isFree } != null }
  27. Infixation val config = EnvironmentVariables overriding ConfigurationProperties.fromResource("default.conf") infix fun Configuration.overriding(defaults:

    Configuration) = Override(this, defaults) (n) An unhealthy obsession with infix functions. fun Author.toJson(): JsonNode = obj( "name" of name, "affiliation" of affiliation.toJson(), "email" of emailAddress ) Unnecessary (but published, so can't be changed without breaking code) Useful
  28. Operator punning Prefer conventional operators or clearly named functions val

    submissionId = PathElement(::SubmissionId) val fileId = PathElement(::FileId) val submissionPath = "submission"/submissionId val submissionFilePath = submissionPath/"file"/fileId WTF?!?
  29. Spaces in Identifiers private fun String.`fromCamelCaseTo space separated`() = this.replace(wordBoundaryRegex,

    "$1 $2") private val wordBoundaryRegex = Regex("(\\p{Ll})(\\p{Lu})") @Test fun `an author cannot edit another author's submission`() … Too jokey & makes client code hard to read Ok – test names act as documentation in IDE views & no client code This limited use case is now supported by IntelliJ's rename refactoring.
  30. Adoption in other projects • Kotlin has spread very quickly

    throughout the organisation • Java, Scala and Python developers pick it up very quickly • People have just been writing code with no respect for our authoritah!
  31. Summary Don't go overboard with Kotlin's "cool" features You can

    start right away! No need for a big-bang port Be aware of how Kotlin differs from Java
  32. Summary •Simultaneously impressed and horrified •Addictive •I wouldn’t hesitate to

    take a Scala contract •Starting a Scala project is less clear-cut •You can live without cutting edge IDE support (?) •Suitable for a bleeding edge team •Is something simpler trying to get out?