Perception and Effects of Implementing Kotlin in Existing Projects

Total Page:16

File Type:pdf, Size:1020Kb

Perception and Effects of Implementing Kotlin in Existing Projects Bachelor thesis Undergraduate level Perception and effects of implementing Kotlin in existing projects A case study about language adoption Author: Emil Sundin Supervisor: Wei Song Examiner: Azadeh Sarkheyli Discipline: Informatics Course: IK2017 Credit: 15 credits Examination date: 2018-05-25 Dalarna University provides the opportunity for publishing the thesis through DiVA as Open Access. This means that the thesis work will become freely available to read and download through their portal. Dalarna University encourages students as well as researchers to publish their work in the Open Access format. We approve the publishing of this thesis work under the Open Access format: Yes ☒ No ☐ Dalarna University – SE-791 88 Falun – Phone +4623-77 80 00 Abstract The Kotlin programming language has seen an increase of adoption since its launch in 2011. In late 2017 Google announced first-class support for Kotlin on the Android platform which further popularized the language. With this increase in popularity we felt it was interesting to investigate how Kotlin affects the developer experience. We performed a case study to see how Java developers perceive the Kotlin language, and how it meets the requirements of these developers. To gather the developer requirements and their perception of Kotlin we performed two sets of interviews and rewrote parts of their codebase. The first set of interviews identified developer requirements and the second set of interviews showcased the Kotlin language and its potential use in their codebase. The results show that Kotlin can meet most of the developer requirements and that the perception of Kotlin is positive. Kotlin’s ability to be incrementally adopted was a prominent feature which reduced the inherent risks of technology adoption while providing them the ability to further evaluate the language. The expressiveness of a programming language has previously been found to be a prominent factor of language adoption. In this study, we identified the expressive nature of Kotlin as a major factor of its adoption potential. Keywords: Kotlin, Language Adoption, Developer Experience, Java, Code Migration Acknowledgements A big thank you to my research partner InfoCaption AB which has been ideal in their cooperation. They’ve been enthusiastic, open to critique and has in a self-aware way provided technical and social insights. Table of contents 1. Introduction ................................................................................................................. 1 1.1 Background ........................................................................................................................ 1 1.2 Problem and research questions ......................................................................................... 3 1.3 Purpose.............................................................................................................................. 3 1.4 Constraints ......................................................................................................................... 3 2. Theory .......................................................................................................................... 4 2.1 Unhappiness of Software Developers .................................................................................. 4 2.2 Empirical Analysis of Programming Language Adoption ....................................................... 5 2.2.1 Power Law ............................................................................................................................. 5 2.2.2 Intrinsic features ................................................................................................................... 5 2.2.3 Forgetfulness ......................................................................................................................... 5 2.2.4 Expressiveness ....................................................................................................................... 5 2.2.5 Motivation for selecting languages ....................................................................................... 5 2.2.6 Valued features ..................................................................................................................... 5 2.2.7 Learning ................................................................................................................................. 5 2.3 Stack Overflow developer survey ........................................................................................ 6 2.3.1 Developer roles ..................................................................................................................... 6 2.3.2 Most popular programming, scripting and markup languages ............................................. 6 2.3.3 Most loved, dreaded and wanted ......................................................................................... 7 2.4 Programming Language Use in US Academia and Industry ................................................... 8 3. Kotlin as a language ...................................................................................................... 9 3.1 Selling points ...................................................................................................................... 9 3.2 Apparent syntax differences ............................................................................................. 10 3.3 Variables .......................................................................................................................... 10 3.3.1 Immutable variables ............................................................................................................ 10 3.3.2 Mutable variable ................................................................................................................. 10 3.3.3 String templates and string literals ..................................................................................... 10 3.4 Functions definitions ........................................................................................................ 11 3.5 Classes and objects ........................................................................................................... 12 3.5.1 Basic classes ........................................................................................................................ 12 3.5.2 With constructor ................................................................................................................. 12 3.5.3 With default parameters ..................................................................................................... 12 3.5.4 Getter and setters ............................................................................................................... 12 3.5.5 POJO and DTO ..................................................................................................................... 13 3.5.6 Inheritance .......................................................................................................................... 13 3.5.7 Singletons ............................................................................................................................ 13 3.6 Extension functions .......................................................................................................... 13 3.7 Null safety ........................................................................................................................ 14 3.8 Miscellaneous convenient features ................................................................................... 15 3.8.1 Use of classes with same name ........................................................................................... 15 3.8.2 Smart casting ....................................................................................................................... 15 4. Method ...................................................................................................................... 16 4.1 Research strategy ............................................................................................................. 16 4.2 Data generation ............................................................................................................... 17 4.2.1 Literature review ................................................................................................................. 17 4.2.2 Informal interview ............................................................................................................... 18 4.2.3 Code introduction and document studies........................................................................... 18 4.2.4 Interviews ............................................................................................................................ 18 4.3 Analysis and execution ..................................................................................................... 19 4.3.1 Summarization and visualization ........................................................................................ 19 4.4 Interview design ............................................................................................................... 20 4.4.1 Pre-interview ....................................................................................................................... 21 4.4.2 Post-interview ..................................................................................................................... 22 4.5 Interviewees ...................................................................................................................
Recommended publications
  • Weld 3.0.2.Final - CDI Reference Implementation
    Weld 3.0.2.Final - CDI Reference Implementation CDI: Contexts and Dependency In- jection for the Java EE platform by Gavin King, Pete Muir, Jozef Hartinger, Martin Kouba, Dan Allen, and David Allen and thanks to Nicola Benaglia, Gladys Guerrero, Eun- Ju Ki,, Terry Chuang, Francesco Milesi, and Sean Wu A note about naming and nomenclature ............................................................................. ix I. Beans ............................................................................................................................ 1 1. Introduction ......................................................................................................... 5 1.1. What is a bean? ......................................................................................... 5 1.2. Getting our feet wet .................................................................................... 5 2. More about beans ................................................................................................ 9 2.1. The anatomy of a bean ............................................................................. 10 2.1.1. Bean types, qualifiers and dependency injection ............................... 10 2.1.2. Scope ............................................................................................ 13 2.1.3. EL name ........................................................................................ 13 2.1.4. Alternatives .................................................................................... 14 2.1.5. Interceptor
    [Show full text]
  • Introduction to Groovy and Grails
    Introduction to Groovy and Grails Mohamed Seifeddine November 25, 2009 1 Contents 1 Foreword 5 2 Introduction to Groovy 7 3 Getting started 9 3.1 Installing Groovy . .9 3.1.1 JDK - A Prerequisite . .9 3.1.2 Installing Groovy . .9 3.2 Updating Groovy . 10 3.3 Editors for Groovy and Grails . 10 3.4 groovysh, groovyConsole & groovy . 10 4 Boolean Evaluation, Elvis Operator & the Safe Navigation Op- erator 13 4.1 Elvis Operator . 15 4.2 Safe Navigation Operator . 15 5 String & GString 19 6 Classes, Dynamic type, Methods, Closures the & Meta-Object Protocol 21 6.1 Dynamic type . 25 6.2 Closure . 29 6.2.1 Create . 29 6.2.2 Call . 30 6.2.3 Getting Information . 33 6.2.4 Method Reference Pointer . 33 6.3 More on Methods . 35 6.3.1 Optional Parantheses . 35 6.3.2 Positional Parameters . 35 6.3.3 Optional Parameters . 36 6.3.4 Mapped Parameters . 37 6.3.5 Dynamic Method Call . 37 6.4 Meta-Object Protocol . 39 6.4.1 Adding Methods & Properties . 39 6.4.2 Add Constructor . 41 6.4.3 Intercepting Method Calls . 41 6.4.4 Getting Information . 42 7 Collections (List, Range, Map) and Iterative Object Methods 47 7.1 List . 47 7.2 Range . 50 7.3 Map . 52 8 Other 55 8.1 Groovy Switch . 55 8.2 Groovy SQL . 56 8.3 File . 58 8.4 Exception Handling . 60 2 8.5 Other . 60 9 Introduction to Grails 61 10 Getting Started 63 10.1 Installing Grails .
    [Show full text]
  • (Minus Sign) in Class Diagrams, 15 * (Asterisk) As Wildcard, 58 ? (Question
    Index - (minus sign) in class diagrams, 15 AOP module (Spring), 34, 37 * (asterisk) as wildcard, 58 Apache Axis web services framework, 210 ? (question mark) for positional bind Apache Maven, 280–285 variables, 187 Apache Struts framework, 23 + (plus sign) in class diagrams, 15 Apache Tiles framework, 122, 278 Apache Tomcat, 257 ■ A APF (Authentication Processing Filter), AbstractCachingViewResolver class, 60 233–243 AbstractCommandController class, 74–78 application contexts (Spring), 33 AbstractController class, 71–74 Application Controller pattern AbstractEnterpriseBean class, 158, 200 action/command handling, 52–56 AbstractHandlerMapping, 54 action handlers, using, 56–58 AbstractMessageDrivenBean class, 200 for action-view management, 50–52 AbstractProcessingFilter, 234 background, 50–51 AbstractStatelessSessionBean, 158 benefits and concerns, 68 AbstractTemplateViewResolver class, strategies with Spring framework, 52 60–61 view handlers, 59–62, 62–68 AbstractWizardFormController class, 89 application server transactions, 261 access decision manager (Spring application servers, 138 Security), 228 application service implementation class, accessDecisionManager property, 164 246–247 Application Service pattern Acegi Security, 223–224 benefits and concerns, 167 action/command handling (application to concentrate business logic in POJO controller), 52–56 classes, 162–163 action handlers strategies with Spring framework, page controllers and, 51 164–167 sequence, 54 applicationContext-security.xml, 229 using (application controller), 56–58
    [Show full text]
  • Develop a Simple Web Application with Apache Wicket and Apache
    Develop a simple Web application with Apache Wicket and Apache Geronimo Combine Wicket, Geronimo, and Apache Derby to form an open source Java Web development platform Skill Level: Intermediate Robi Sen ([email protected]) Vice President Department 13 LLC 10 Jul 2007 Apache Wicket is an innovative Java™ Web application framework that was introduced a couple of years ago. It helps simplify Web application development by clearly separating the roles of developers and designers. It lets you remove logical code from the view layer, eliminating the need for JavaServer Pages (JSP), providing a simple plain old Java object (POJO)-centric mode of development, and removing much of the need for XML and other configuration file formats. In this tutorial, learn how to set up your system to develop a simple Web application with Wicket, using Apache Geronimo as your application server and Apache Derby as the embedded database. Section 1. Before you start This tutorial is designed for developers who have found Java frameworks, such as Struts, lacking in needed functionality. If you're interested in developing Web applications in a more object-oriented manner, where the view is clearly separated from logic and there's minimal configuration and mapping, then Wicket is for you! This tutorial walks you through the basics of how Wicket works, while using Apache Geronimo to set up a Java Platform, Enterprise Edition (Java EE) server, Web server, and embedded database in just minutes. Combining Wicket with Geronimo lets you develop data-driven, scalable Web applications using software that's all open source. Develop a simple Web application with Apache Wicket and Apache Geronimo © Copyright IBM Corporation 1994, 2008.
    [Show full text]
  • Towards High-Quality Android Applications Development with Kotlin Bruno Gois Mateus
    Towards high-quality Android applications development with Kotlin Bruno Gois Mateus To cite this version: Bruno Gois Mateus. Towards high-quality Android applications development with Kotlin. Mobile Computing. Université Polytechnique Hauts-de-France, 2021. English. NNT : 2021UPHF0012. tel- 03247062 HAL Id: tel-03247062 https://tel.archives-ouvertes.fr/tel-03247062 Submitted on 2 Jun 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. PhD Thesis Université Polytechnique Hauts-de-France and from INSA Hauts-de-France Subject: Computer Science Presented and defended by Bruno GÓIS MATEUS On March 26, 2021, Valenciennes Doctoral School: Sciences Pour l’Ingénieur (ED SPI 072) Research team, Laboratory: Département d’Informatique Laboratory of Industrial and Human Automation control, Mechanical engineering and Computer Science (LAMIH UMR CNRS 8201) Towards high-quality Android applications development with Kotlin JURY Committee President - Káthia MARÇAL DE OLIVEIRA. Professor at Université Polytechnique Hauts-de-France. Reviewers - Guilherme HORTA TRAVASSOS. Professor at Federal University of Rio de Janeiro. - Jacques KLEIN. Professor at University of Luxembourg. Examiner - Dalila TAMZALIT. Associate Professor at Université de Nantes. Supervisor - Christophe KOLSKI. Professor at Université Polytechnique Hauts-de-France. Co-Supervisor - Matias MARTINEZ.
    [Show full text]
  • Esper Reference
    Esper Reference Version 8.3.0 by EsperTech Inc. [http://www.espertech.com] Copyright 2006 - 2019 by EsperTech Inc. Preface ......................................................................................................................... xxvii 1. Getting Started ............................................................................................................ 1 1.1. Introduction to Complex Event Processing ........................................................... 1 1.2. Introduction to the Architecture ............................................................................ 1 1.3. Introduction to EPL ............................................................................................. 2 1.4. Compiler Getting-Started ..................................................................................... 3 1.4.1. Compiler - Step One: Setting up the Compiler Classpath ............................ 3 1.4.2. Compiler - Step Two: Provide Information on Input Events .......................... 3 1.4.3. Compiler - Step Three: Compiling EPL ...................................................... 4 1.5. Runtime Getting-Started ...................................................................................... 5 1.5.1. Runtime - Step One: Setting up the Runtime Classpath .............................. 5 1.5.2. Runtime - Step Two: Obtain Runtime ........................................................ 6 1.5.3. Runtime - Step Three: Deploy EPL Compiled Module and Attach a Callback .........................................................................................................................
    [Show full text]
  • Groovy and Java: a Comparison Groovy’S Resemblance to Java Is Often Quite Striking
    APPENDIX ■ ■ ■ The Groovy Language Groovy is an all-purpose programming language for the JVM. It was born in 2003 when James Strachan and Bob McWhirter founded the Groovy project with the goal of creating a glue lan- guage to easily combine existing frameworks and components. Groovy is a language that aims to bring the expressiveness of languages such as Ruby, Lisp, and Python to the Java platform while still remaining Java friendly. It attracted much excitement with these ambitious goals, because the majority of other scripting languages on the Java platform either used an entirely alien syntax and APIs or were simply Java without the need to specify types. Despite its youth, Groovy is a stable, feature-rich language that forms the perfect base for Grails. This is a fantastic achievement, given the limited resources available to an open source project such as Groovy. Groovy was an obvious choice as a platform for the Grails framework, because it provides the necessary underlying infrastructure to create the diverse range of miniature domain-specific languages utilized throughout Grails. ■Note Martin Fowler has written an excellent article about domain-specific languages: http://www.mar- tinfowler.com/bliki/DomainSpecificLanguage.html. What does this mean? Well, the syntax you see used throughout the book has often been magically enhanced and shortened by using a combination of Groovy’s already concise syntax and its support for metaprogramming. Groovy performs a lot of magic under the covers, abstracted away from the developer. This removes the burden from the programmer who would otherwise be required to write reams of unnecessary, repetitive code.
    [Show full text]
  • An Object Relational Mapping Technique for Java Framework
    International Journal of Engineering Science Invention ISSN (Online): 2319 – 6734, ISSN (Print): 2319 – 6726 www.ijesi.org Volume 2 Issue 6 ǁ June. 2013 ǁ PP.01-09 An Object Relational Mapping Technique for Java Framework Ogheneovo, Edward Erhieyovwe,1 Asagba, Prince Oghenekaro,1 Ogini, Nicholas Oluwole2 1College of Natural and Applied Sciences, Faculty of Physical and Information Technology, Department of Computer Science, University of Port Harcourt, Port Harcourt, PMB 5323, Choba, Rivers State, Nigeria 2Faculty of Science, Department of Mathematics and Computer Science, Delta State University, Abraka, Delta State, Nigeria ABSTRACT: Database technology is in a period of intensive change and innovation that is both revolutionary and evolutionary. The revolutionary aspect refers to the innovation of an object-oriented programming technology. Object relational mapping (ORM) frameworks address the impedance problem of software implementation level. In this paper, we discussed the problem of building an object relational mapping by presenting a framework based on Java platform that will guide developer in handling incompatibility issues. This paper exploits the powerful features of Java as a managed object-oriented platform. The major goal of the work is to map data between incompatible type systems in the object-oriented programming language by linking the SQL database to object-oriented language concepts, thus creating in effect a “virtual object database”. The work discusses how a mini bank application can be designed and implemented as well as mapping of the object- oriented constructs to entities of the relational databases. Implementing the design in code is a straightforward process that results in two Java class libraries (.JAR files) that have to be deployed in the development environment.
    [Show full text]
  • 451 Angular CLI, 77, 412 Component, 89 Detection, 398–399 Http Client, 320–321 Module System, 119 Deployment, 130 Ex100
    Index A AngularJS vs. Angular Angular JavaScript using JavaScript CLI, 77, 412 engines, 18 component, 89 platform, 17 detection, 398–399 semantic versioning, 16–17 Http client, 320–321 shims and polyfills, 18 module system, 119 controllers and components, 22 deployment, 130 dependency and constructor ex100, 123–126, 128–129 injection, 22–23 feature module, 122–123 forms, 24 Node commands, 131 modules, 21 root module, 121 module system, 116 routing module, 122 scope, controllers, and components, 24 shared module, 123 templates, 25 Start project, 120–121 Annotations, 91 pipes app.component.spec.ts, 412 combining date formats, 388 Application component, 89 currency, 386 Asynchronous data streams date, 386 event-based reactive programs, 291 json, 388 observable sequences, 292 lowercase, 385 observers, 292–294 percentage, 386 operators predefined date formats, 387 buffer, 300 shortdate, 386 debounce, 302–303 UK pound currency, 386 distinct, 304 uppercase, 385 filter, 304 variety of, 388, 390 from, 298 uses observables, 310 interval, 298 451 © Mark Clow 2018 M. Clow, Angular 5 Projects, https://doi.org/10.1007/978-1-4842-3279-8 INDEX Asynchronous data streams (cont.) Command line interface (CLI) map, 301 bootstrapping, 84–85 of (Was just), 299 compilation, 86 range, 299 compile errors, 82 repeat, 299 creating project, 78–79 scan, 301 file watcher and web server, 84 share, 306–307 modifying project, 81 take, 305 options, 85 timer, 300 root folder, 80 subscription, 295 runtime errors, 82 Asynchronous JavaScript and XML (AJAX) source code, 80 callbacks, 6 Component(s) encoding, 7–8 child, 159–160 HAL and HATEOAS, 8–10 class, 97 JSON and XML, 5 class life cycle promises, 6 constructor vs.
    [Show full text]
  • Less Code, More Fun
    KOTLIN LESS CODE, MORE FUN Speaker notes Michael Fazio - @faziodev + 1 Speaker notes + 2 . 1 Speaker notes I work here! 2 . 2 Speaker notes + 3 . 1 Speaker notes + 3 . 2 Speaker notes + 3 . 3 Speaker notes + 3 . 4 3 . 5 WHAT IS... Speaker notes First unveiled in 2011 (after being in dev for a year) Open-sourced in 2012 Version 1.0 released on February 15th, 2016 JetBrains said most languages were lacking the features they wanted Except Scala, but it was slow to compile JetBrains hopes to drive IntelliJ sales 4 . 1 "STATICALLY TYPED PROGRAMMING LANGUAGE FOR MODERN MULTIPLATFORM APPLICATIONS" 4 . 2 STATICALLY TYPED val numbers: List<Int> = listOf(1, 4, 7, 10, 23) enum class Sport { Baseball, Football, Soccer, Basketball } data class Team(val city: String, val teamName: String, val sport: Spo Speaker notes Staticallyval teamtyped: = Team("Milwaukee", "Brewers", Sport.Baseball) Know type of variable at compile time Java C, C++, C# Kotlin uses type inference Type system can figure the type out Don't always have to specify Will warn if not clear Modern: Concise code Lots of features 4 . 3 MULTI-PLATFORM Speaker notes First-class language on Android Interoperable with JVM Transpile Kotlin into JavaScript Compile native code (without VM) Windows Linux MacOS iOS Android WebAssembly 4 . 4 100% JAVA INTEROPERABILITY import io.reactivex.Flowable import io.reactivex.schedulers.Schedulers Flowable .fromCallable { Thread.sleep(1000) // imitate expensive computation "Done" } .subscribeOn(Schedulers.io()) .observeOn(Schedulers.single()) .subscribe(::println, Throwable::printStackTrace) Speaker notes Call existing Java libraries Use Java classes Can call Kotlin classes from Java May need a bit of tweaking 4 .
    [Show full text]
  • Groovy Basicsbasics
    GroovyGroovy BasicsBasics SangSang ShinShin JPassion.comJPassion.com ““LearnLearn withwith Passion!”Passion!” 1 Topics • What is and Why Groovy? • Groovy Syntax • Differences from Java • Refactoring Java code into Groovy code • Inter-operating with Java • Groovy Ecosystem 2 WhatWhat isis && WhyWhy Groovy?Groovy? What is Groovy? • Dynamic, objected oriented, scripting language for JVM • Seamless integration with Java > Designed with Java in mind from the beginning (unlike other scripting languages) > Easy to learn for Java programmers • Borrowed language features from Ruby, Python, Smalltalk 4 Why Groovy over Other Scripting Languages? • Groovy is a dynamic language “specifically” designed for Java platform > Leverage the benefit of JVM • Groovy provides an effortless transition from Java > Groovy code, when compiled, generated Java bytecode > Existing Java code works in Groovy environment “as it is” basis > Incremental change is possible, in fact, recommended (when you plan to migrate existing Java code to Groovy) 5 Groovy IS Java (or BETTER Java) • Provides syntactic sugar > Easy and fun to code (like Ruby) • Provides new language features over Java > Closure (Java 8 now supports closure through Lambda) > Meta-programming • Provides easier development environment > Scripting > Combines compilation and execution into a single step > Shell interpreter 6 LabLab ExerciseExercise 0:0: InstallInstall GroovyGroovy ExerciseExercise 1:1: GroovyGroovy isis JavaJava 5610_groovy_basics.zip5610_groovy_basics.zip 7 WhyWhy GroovyGroovy (or(or Scala)?Scala)?
    [Show full text]
  • Copyrighted Material
    20_777106 bindex.qxp 11/28/06 10:49 PM Page 715 Index Index SYMBOLS AND A abstraction, 126 NUMERICS access 2-byte Unicode strings, 433 to databases, 311 200 (HTTP response code), 532 to fields, 442–445 403 (HTTP response code), 532 in JNI, 442–445 404 (HTTP response code), 532 access control, 585–586 500 (HTTP response code), 532 accessor methods, 104 @AroundInvoke annotation, 481, 484 Action classes. See also specific types, e.g.: XWork @AttributeOverride annotation, 490 Action @Column annotation, 479 IoC and, 401 @deprecated annotation, 27 in WebWork, 399 @Discriminator annotation, 488 of XWork, 399, 412–415 @EJB annotation, 490 ActionListener interface, 163, 205, 217–218 @Entity annotation, 487 actionPerformed method, 163, 205, 213 @Id annotation, 478 Adapter pattern @Interceptors annotation, 481 using, 126 @MappedSuperclass annotation, 489 Adaptee interface in, 133 @OneToMany annotation, 478 Adapter interface in, 133 @overrides annotation, 27 Client interface in, 132 @PersistenceContext annotation, 487 discussed, 131–132 @PersistenceContexts annotation, 487 Target interface in, 132 @PersistenceUnit annotation, 487 addActionListener method, 205 @PersistenceUnits COPYRIGHTED MATERIAL annotation, 487 addFolder method, 466 @Remote annotation, 483 adding data @Resource annotation, 380–381 in EJB database, 476, 477 @Stateless annotation, 497 in EntityManager API, 477–478 @TransactionAtrribute marking, 508 in Hibernate, 412 @TransactionManagement annotation, 508 to Model 2 system, 417–419 @Transient annotation, 512 web application visualization
    [Show full text]