• Comparing Lombok and Kotlin

    I know about Lombok since a long time, and I even wrote on how to create a new (at the time) @Delegate annotation. Despite this and even though I think it’s a great library, I’ve never used it in my projects. The reason for this mostly because I consider setting up the Lombok agent across various IDEs and build tools too complex for my own taste in standard development teams.

    Comes Kotlin which has support for IDEs and build tools right out-of-the-box plus seamless Java interoperability. So, I was wondering whether Lombok would still be relevant. In this article, I’ll check if Kotlin offers the same feature as Lombok and how. My goal is not to downplay Lombok’s features in a any way, but to perform some fact-checking to let you decide what’s the right tool for you.

    The following assumes readers are familiar with Lombok’s features.

    LombokSnippetKotlin equivalent
    val
    val e = new ArrayList<String>();
    val e = ArrayList<String>()
    @NonNull
    public void f(@NonNull String b) {
        ....
    }
    fun f(b: String) {
      ...
    }
    Kotlin types can be either nullable i.e. String? or not i.e. String. Such types do no inherit from one another.
    @Cleanup
    @Cleanup
    InputStream in =
        new FileInputStream("foo.txt")
    FileInputStream("foo.txt").use {
      // Do stuff here using 'it'
      // to reference the stream
    }
    • use() is part of Kotlin stdlib
    • Referencing the stream is not even necessary
    @NoArgsConstructor, @RequiredArgsConstructor and @AllArgsConstructor No equivalent as class and constructor declaration are merged
    @Getter
    public class Foo {
        @Getter
        private String bar;
    }
    class Foo() {
      var bar:String? = null
        private set
    }
    • Generates a private setter instead of no setter
    • Not idiomatic Kotlin (see below)
    public class Foo {
        @Getter
        private String bar;
        public Foo(String bar) {
            this.bar = bar;
        }
    }
    class Foo(val bar:String)
    Takes advantage of merging class and constructor declaration with slightly different semantics
    @Setter
    public class Foo {
        @Setter
        private String bar;
    }
    No equivalent but pretty unusual to just have a setter (does not favor immutability)
    public class Foo {
        @Setter
        private String bar;
        public Foo(String bar) {
            this.bar = bar;
        }
    }
    class Foo(var bar: String)
    @ToString No direct equivalent but included in data classes, see below
    @EqualsAndHashCode
    @Data
    @Data
    public class DataExample {
        private String name;
        private int age;
    }
    data class DataExample(
      var name: String,
      var age: Int)
    @Value
    @Value
    public class ValueExample {
      String name;
      int age;
    }
    data class ValueExample(
      val name: String,
      val age: Int)
    Notice the difference between val and var with the above snippet
    lazy=true
    public class GetterLazyExample {
      @Getter(lazy=true)
      private Double cached = expensive();
    }
    class GetterLazyExample {
      val cached by lazy {
        expensive()
      }
    }
    @Log
    @Log
    public class LogExample {
      public static void main(String... args) {
        log.error("Something's wrong here");
      }
    }
    No direct equivalent, but possible in many different ways
    @SneakyThrows
    @SneakyThrows
    public void run() {
     throw new Throwable();
    }
    fun run() {
      throw Throwable()
    }
    There's no such thing as checked exceptions in Kotlin. Using Java checked exceptions requires no specific handling.
    @Builder
    @Builder
    public class BuilderExample {
      private String name;
      private int age;
    }
    
    BuilderExample b = new BuilderExampleBuilder()
      .name("Foo")
      .age(42)
      .build();
    class BuilderExample(
      val name: String,
      val age: Int)
    
    val b = BuilderExample(
      name = "Foo",
      age = 42
    )
    No direct equivalent, use named arguments instead.
    @Synchronized
    public class SynchronizedExample {
      private final Object readLock = new Object();
      @Synchronized("readLock")
      public void foo() {
        System.out.println("bar");
      }
    }
    It's possible to omit to reference an object in the annotation: Lombok will create one under the hood (and use it).
    class SynchronizedExample {
      private val readLock = Object()
      fun foo() {
        synchronized(readLock) {
          println("bar")
        }
      }
    }
    synchronized() is part of Kotlin stdlib
    Experimental features
    LombokSnippetKotlin equivalent
    @ExtensionMethod
    class Extensions {
      public static String extends(String in) {
        // do something with in and
        return it;
      }
    }
    
    @ExtensionMethod(
      {String.class, Extensions.class}
    )
    public class Foor {
      public String bar() {
        return "bar".toTitleCase();
      }
    }
    fun String.extends: String {
      // do something with this and
      return it;
    }
    
    class Foo {
      fun bar = "bar".toTitleCase()
    }
    @Wither No direct equivalent, available through data classes
    @FieldDefaults
    class Foo(val bar: String = "bar")
    @Delegate Available in many different flavors
    @UtilityClass
    @UtilityClass
    public class UtilityClassExample {
      private final int CONSTANT = 5;
      public void addSomething(int in) {
        return in + CONSTANT;
      }
    }
    val CONSTANT = 5
    fun addSomething(i: Int) = i + CONSTANT
    @Helper
    public class HelperExample {
      int someMethod(int arg1) {
        int localVar = 5;
        @Helper class Helpers {
          int helperMethod(int arg) {
            return arg + localVar;
          }
        }
        return helperMethod(10);
      }
    }
    class HelperExample {
      fun someMethod(arg1: Int): Int {
        val localVar = 5
        fun helperMethod(arg: Int): Int {
          return arg + localVar
        }
        return helperMethod(10)
      }
    }

    In conclusion:

    • Lombok offers some more features
    • Lombok offers some more configuration options, but most don’t make sense taken separately (e.g. data classes)
    • Lombok and Kotlin have slightly different semantics when a feature is common so double-check if you’re a Lombok user willing to migrate

    Of course, this post completely left out Kotlin’s original features. This is a subject left out for future articles.

    Categories: Java Tags: lombokkotlin
  • Faster Mutation Testing

    As an ardent promoter of Mutation Testing, I sometimes get comments that it’s too slow to be of real use. This is always very funny as it also applies to Integration Testing, or GUI. Yet, this argument is only used againt Mutation Testing, though it cost nothing to setup, as opposed to the former. This will be the subject of another post. In this one, I will provide proposals on how to speed up mutation testing, or more precisely PIT, the Java Mutation Testing reference.

    Setting the bar

    A project reference for this article is required. Let’s use the codec submodule of Netty 4.1.

    At first, let’s compile the project to measure only PIT-related time. The following should be launched at the root of the Maven project hierarchy:

    mvn -pl codec clean test-compile
    

    The -pl option let the command be applied to only specified sub-projects - the codec sub-project in this case. Now just run the tests:

    mvn -pl codec surefire:test
    
    ...
    Results :
    
    Tests run: 340, Failures: 0, Errors: 0, Skipped: 0
    
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 8.954 s
    [INFO] Finished at: 2016-06-13T21:41:10+02:00
    [INFO] Final Memory: 12M/309M
    [INFO] ------------------------------------------------------------------------
    

    For all it’s worth, 9 seconds will be the baseline. This is not really precise measurement, but good enough for the scope of this article.

    Now let’s run PIT:

    mvn -pl codec -DexcludedClasses=io.netty.handler.codec.compression.LzfDecoderTest \
     org.pitest:pitest-maven:mutationCoverage
    

    Note: PIT flags the above class as failing, even though Surefire has no problem about that

    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 14:14 min
    [INFO] Finished at: 2016-06-13T22:02:48+02:00
    [INFO] Final Memory: 14M/329M
    

    A whooping 14 minutes! Let’s try to reduce the time taken.

    Speed vs. relevancy trade-off

    There is no such thing as a free lunch.

    PIT offers a lot of tweaks to improve testing speed. However, most of them imply a huge drop in relevancy: faster means less feedback on code quality less than complete. As it’s the ultimate goal of Mutation Testing, it’s IMHO meaningless.

    Those configuration options are:

    • Set a limited a set of mutators
    • Limit scope of target classes
    • Limit number of tests
    • Limit dependency distance

    All benefits those flags bring are negated by less information.

    Running on multiple cores

    By default, PIT uses a single core even though most personal computers, not to mention servers have many more available.

    The easiest way to run faster is to use more cores. If it takes X minutes to run PIT on a single core, and if Y additional cores are 100% available, then it should only take X / (Y + 1) minutes to run on the first and additional cores.

    The number of cores is governed by the thread Java system property when launching Maven.

    mvn -pl codec -DexcludedClasses=io.netty.handler.codec.compression.LzfDecoderTest \
     -Dthreads=4 org.pitest:pitest-maven:mutationCoverage
    

    This yields the following results, which probably means that those additional cores were already performing some tasks during the run.

    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 07:30 min
    [INFO] Finished at: 2016-06-13T22:25:38+02:00
    [INFO] Final Memory: 15M/318M
    

    Still, 50% is good enough for such a small configuration effort.

    Incremental analysis

    The rationale between incremental analysis is that unchanged tests running unchanged classes will produce the same outcome as the last one.

    Hence, PIT will create a hash for every test and production class. If they are similar, the test won’t run and PIT will reuse the same result. This just requires to configure where to store those hashes.

    Let’s run PIT with incremental analysis. The historyInputFile system property is the file where PIT will read hashes, historyOutputFile the file where it will write them. Obviously, they should point to the same file; anyone care to enlighten me as why they can be different? Anyway:

    mvn -pl codec -DexcludedClasses=io.netty.handler.codec.compression.LzfDecoderTest \
     -DhistoryInputFile=~/.fastermutationtesting -DhistoryOutputFile=~/.fastermutationtesting \
     -Dthreads=4 org.pitest:pitest-maven:mutationCoverage
    

    That produces:

    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 07:05 min
    [INFO] Finished at: 2016-06-13T23:04:59+02:00
    [INFO] Final Memory: 15M/325M
    

    That’s about the time of the previous run… It didn’t run any faster! What could have happened? Well, that’s the first run so that hashes were not created. If PIT is ran again a second time with the exact same command-line, the output is now:

    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 17.806 s
    [INFO] Finished at: 2016-06-13T23:12:43+02:00
    [INFO] Final Memory: 20M/575M
    

    That’s way better! Just the time to startup the engine, create the hashes and compare them.

    Using SCM

    An alternative to the above incremental analysis is to delegate change checks to the VCS. However, that requires the scm section to be adequately configured in the POM and the usage of the scmMutationCoverage goal in place of the mutationCoverage one.

    Note this is the reason why Maven should be launched at the root of the project hierarchy, to benefit from the SCM configuration in the root POM.

    mvn -pl codec -DexcludedClasses=io.netty.handler.codec.compression.LzfDecoderTest \
     -Dthreads=4 org.pitest:pitest-maven:scmMutationCoverage
    

    The output is the following:

    [INFO] No locally modified files found - nothing to mutation test
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 7.587 s
    [INFO] Finished at: 2016-06-14T22:11:29+02:00
    [INFO] Final Memory: 14M/211M
    

    This is even faster than incremental analysis, probably since there’s no hash comparison involved.

    Changing files without committing will correctly send the related mutants to be tested. Hence, this goal should be used only be developers on their local repository to check their changes before commit.

    Conclusion

    Now that an authoritative figure has positively written about Mutation Testing, more and more people will be willing to use it. In that case, the right configuration might make a difference between wide adoption and complete rejection.

    Categories: Java Tags: mutation testingqualityperformance
  • Smart logging in Java 8 and Kotlin

    Logging is a not a sexy subject but it’s important nonetheless. In the Java world, logging frameworks range from Log4J to SLF4J via Commons Logging and JDK logging (let’s exclude Log4J 2 for the time being). Though different in architecture and features, all of their API look the same. The logger has a method for each log level e.g.:

    • debug(String message)
    • info(String message)
    • error(String message)
    • etc.

    Levels are organized into a hierarchy. Once the framework is configured at a certain level, only messages logged with the same or a higher priority will be written.

    So far, so good. The problem comes when messages contain variables so that they must be concatenated.

    LOGGER.debug("Customer + " customer.getId() + " has just ordered " + item.getName() + " (" + item.getId() + ")");
    

    String concatenation has a definite performance cost in Java, and whatever the configured log level, it will occur.

    For this reason, modern logging frameworks such as SLF4J provide improved signature accepting a message format typed as String and variables as varargs of Objects. In that case, concatenation occurs only when the logger effectively writes.

    LOGGER.debug("Customer {} has just ordered {} ({})", customer.getId(), item.getName(), item.getId());
    

    Sometimes, however, variables are not readily available but have to be computed explicitly solely for the purpose of logging.

    LOGGER.debug("Customer {} has just ordered {}", customer.getId(), order.expensiveComputation());
    

    SLF4J doesn’t help there, as the method is evaluated even if the logger decides latter not to write because the framework is configured with a higher priority. In that case, it’s therefore advised to wrap the logger method call inside a relevant priority check.

    if (LOGGER.isDebug()) {
        LOGGER.debug("Customer {} has just ordered {}", customer.getId(), order.expensiveComputation());
    }
    

    That has to be done for every expensive method call, so it requires a strong coding discipline and reviews to make sure the wrapping occurs when it’s relevant - but only then. Besides, it decreases readability and thus maintainability. To achieve the same result automatically without those cons, one could use AOP at the cost of extra-complexity.

    Comes Java 8 and the Supplier<T> interface which returns a String, so that a method can be created like so:

    public void debug(Supplier<String> s) {
       if (LOGGER.isDebugEnabled()) {
            LOGGER.debug(s.get());
       }
    }
    

    In that case, the get() method is called only when the wrapping condition evaluates to true.

    Using this method is as simple as that:

    debug(() -> ("Customer + " customer.getId() + " has just ordered " + order.expensiveComputation());
    

    Great! But where to put this improved debug() method?

    • In the class itself: and duplicate for every class. Really?
    • In an utility class: one should add the LOGGER as the first parameter. Did you say cumbersome?
    • In the logger: one can create a wrapper and keep a standard logger as a delegate but the factory is final (at least in SLF4J) and has a lot of private methods.
    • In an aspect: back to square one…

    That’s the step where things start not being so nice in the Java realm.

    What about Kotlin? It comes with extension functions (and properties). This will probably be the subject of a future post since you should adopt Kotlin if only for this feature. Suffice to say that Kotlin can make it look like one can add state and behavior for already defined types.

    So debug() can be defined in a aptly named file:

    fun Logger.debug(s: () -> String) {
        if (isDebugEnabled) debug(s.invoke())
    }
    

    And calling it really feels like calling a standard logger, only a lambda is passed:

    LOGGER.debug { "Customer + " customer.getId() + " has just ordered " + order.expensiveComputation() }
    

    As a finishing touch, let’s make the defined function inlined. By doing that, the compiler will effectively replace every place the method is called with the method in the bytecode. We get the readable syntax benefit and avoid the overhead of un-wrapping the lambda at runtime:

    inline fun Logger.debug(s: () -> String) {
        if (isDebugEnabled) debug(s.invoke())
    }
    

    Note that it can still be called in Java, albeit with a not-so-nice syntax:

    Slf4KUtilsKt.debug(LOGGER, () -> "Customer + " + customer.getId() + " has just ordered " + order.expensiveComputation());
    

    Also note that Log4J 2 already implements this feature out-of-the-box.

    At this point, it’s simple enough to copy-code the above snippet when required. But developers are lazy by nature so I created a full-fledged wrapper around SLF4J methods. The source code is available on Github and the binary artifact on Bintray so that you only need the following dependency to use it:

    <dependency>
      <groupId>ch.frankel.log4k</groupId>
      <artifactId>slf4k-api</artifactId>
      <version>1.0.0</version>
    </dependency>
    
    Categories: Development Tags: kotlinloggingperformance
  • Encapsulation: I don't think it means what you think it means

    My post about immutability provoked some stir and received plenty of comments, from the daunting to the interesting, both on reddit and here.

    Comment types

    They can be more or less divided into those categories:

    • Let’s not consider anything and don’t budge an inch - with no valid argument beside “it’s terrible”
    • One thread wondered about the point of code review, to catch bugs or to share knowledge
    • Rational counter-arguments that I’ll be happy to debate in a future post
    • “It breaks encapsulation!” This one is the point I’d like to address in this post.

    Encapsulation, really?

    I’ve already written about encapsulation but if the wood is very hard, I guess it’s natural to hammer down the nail several times.

    Younger, when I learned OOP, I was told about its characteristics:

    1. Inheritance
    2. Polymorphism
    3. Encapsulation

    This is the definition found on Wikipedia:

    Encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:
    • A language mechanism for restricting direct access to some of the object's components.
    • A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
    -- Wikipedia

    In short, encapsulating means no direct access to an object’s state but only through its methods. In Java, that directly translated to the JavaBeans conventions with private properties and public accessors - getters and setters. That is the current sad state that we are plagued with and that many refer to when talking about encapsulation.

    For this kind of pattern is no encapsulation at all! Don’t believe me? Check this snippet:

    public class Person {
    
        private Date birthdate = new Date();
    
        public Date getBirthdate() {
            return birthdate;
        }
    }
    

    Given that there’s no setter, it shouldn’t be possible to change the date inside a Person instance. But it is:

    Person person = new Person();
    Date date = person.getBirthdate();
    date.setTime(0L);
    

    Ouch! State was not so well-encapsulated after all…

    It all boils down to one tiny little difference: we want to give access to the value of the birthdate but we happily return the reference to the birthdate field which holds the value. Let’s change that to separate the value itself from the reference:

    public class Person {
    
        private Date birthdate = new Date();
    
        public Date getBirthdate() {
            return new Date(birthdate.getTime());
        }
    }
    

    By creating a new Date instance that shares nothing with the original reference, real encapsulation has been achieved. Now getBirthdate() is safe to call.

    Note that classes that are by nature immutable - in Java, primitives, String and those that are developed like so, are completely safe to share. Thus, it’s perfectly acceptable to make fields of those types public and forget about getters.

    Note that injecting references e.g. in the constructor entails the exact same problem and should be treated in the same way.

    public class Person {
    
        private Date birthdate;
    
        public Person(Date birthdate) {
            this.birthdate = new Date(birthdate.getTime());
        }
    
        public Date getBirthdate() {
            return new Date(birthdate.getTime());
        }
    }
    

    The problem is that most people who religiously invoke encapsulation blissfully share their field references to the outside world.

    Conclusions

    There are a couple of conclusions here:

    • If you have mutable fields, simple getters such as those generated by IDEs provide no encapsulation.
    • True encapsulation can only be achieved with mutable fields if copies of the fields are returned, and not the fields themselves.
    • Once you have immutable fields, accessing them through a getter or having the field final is exactly the same.

    Note: kudos to you if you understand the above meme reference.

    Categories: Development Tags: designobject oriented programming
  • Rolling dice in Kotlin

    A little more than 2 years ago, I wrote a post on how you could create a Die rolling API in Scala. As I’m more and more interested in Kotlin, let’s do that in Kotlin.

    At the root of the hierarchy lies the Rollable interface:

    interface Rollable<T> {
        fun roll(): T
    }
    

    The base class is the Die:

    open class Die(val sides: Int): Rollable<Int> {
    
        init {
            val random = new SecureRandom()
        }
    
        override fun roll() = random.nextInt(sides)
    }
    

    Now let’s create some objects:

    object d2: Die(2)
    object d3: Die(3)
    object d4: Die(4)
    object d6: Die(6)
    object d10: Die(10)
    object d12: Die(12)
    object d20: Die(20)
    

    Finally, in order to make code using Die instances testable, let’s change the class to inject the Random instead:

    open class Die(val sides: Int, private val random: Random = SecureRandom()): Rollable<Int> {
        override fun roll() = random.nextInt(sides)
    }
    

    Note that the random property is private, so that only the class itself can use it - there won’t even be a getter.

    The coolest thing about that I that I hacked the above code in 15 minutes in the plane. I love Kotlin :-)

    Categories: Development Tags: apikotlin
  • Software labels translation is not so easy

    Some developers have hardly ever touched software labels translation, some do it on a day-to-day basis. It sure helps to work in a country with more than one language – official or de facto.

    Even for in the first case, it’s considered good practice to externalize labels in properties files. As for the second case, languages are in general related.

    In Java, the whole label translation mechanism is handled through a hierarchy of properties files. At the top of the hierarchy lies the root file, at the second level language-specific files and finally at the bottom country-specific files (let’s forget about lower levels since I haven’t seen them used in 15 years). The translation for message strings are searched along a specific locale, starting from most specific – country, up to the root. If the translation is found at any level, the resolution mechanism stops there and the label is returned.

    As a simple example, let’s take a simple use-case, displaying the number of items on a list. I’d need probably 3 labels:

    • No item found
    • One item found
    • Multiple items found

    This is probably the resulting messages.properties file:

    result.found.none=No item found
    result.found.one=One item found
    result.found.multiple={0} items found
    

    Things get interesting when the customer wants to translate the software after the initial release into an un-related language. Let’s not go as far as pictograph-based languages such as Mandarin Chinese or RTL languages such as Arabic, but use Russian, a language I’m trying to learn (emphasis on try).

    Russian is a language that has https://en.wikipedia.org/wiki/Case[cases], like in Latin.

    Case is a grammatical category whose value reflects the grammatical function performed by a noun or pronoun in a phrase, clause, or sentence. In some languages, nouns, pronouns, and their modifiers take different inflected forms depending on what case they are in. […]

    Commonly encountered cases include nominative, accusative, dative, and genitive. A role that one of these languages marks by case will often be marked in English using a preposition.
    -- Wikipedia

    So, what the fuss about it? Just translate the file and be done with it! Well, Russian is an interesting language for counting. With one, you’d use singular, from 2 to 4, you’d use plural and nominative case, but starting from 5, you use plural and genitive case – indicating quantity.

    Now keys will look like the following (the messages are not very important by themselves):

    • result.found.none
    • result.found.one
    • result.found.twotofour
    • result.found.five

    Is it OK to translate, now? Not quite. Russian is derived from old Slavic and old Slavic had three grammatical numbers: singular, plural and dual. Russian has only singular and plural but there’s a remnant of that for the feminine case. In this case, you’d use две instead of два.

    This requires the following keys:

    • result.found.none
    • result.found.one
    • result.found.two.feminine
    • result.found.two.notfeminine
    • result.found.threetofour
    • result.found.five

    And this only for the things I know. I’m afraid there might be more rules than I don’t know about.

    There are a couple of lessons to learn here:

    1. Translations are not straightforward, especially when the target is a language with different roots.
    2. i18n is much larger and harder than just translations. Think about dates: should month or day come first? And l10n is even larger and harder than i18n.
    3. The cost of translation is not null, and probably will be higher than expected. Estimates are hard, and wrong most of the times.
    4. Never ever assume anything. Implicit is bad in software projects…
    Categories: Java Tags: i18n
  • Immutable data structures in Java

    Before being software developers, we are people - and thus creatures of habits. It’s hard for someone to change one’s own habits, it’s harder for someone to change someone else’s habits - and for some of us, it’s even harder.

    This, week, during a code review, I stumbled upon this kind of structure:

    public class MyStructure {
    
        private String myProp1;
        private String myProp2;
        // A bunch of other String properties
    
        public MyStructure(String myProp1, String myProp2 /* All other properties here */) {
            this.myProp1 = myProp1;
            this.myProp2 = myProp2;
            // All other properties set there
        }
    
        public String getMyProp1() { ... }
        public String getMyProp2() { ... }
        // All other getters
    
        public void setMyProp1(String myProp1) { ... }
        public void setMyProp2(String myProp2) { ... }
        // All other setters
    }
    
    

    Note: it seems like a JavaBean, but it’s not because there’s no no-argument constructor.

    Looking at the code, I see that setters are never used in our code, making it a nice use-case for an immutable data structure - and saving a good number of lines of code:

    public class MyStructure {
    
        private final String myProp1;
        private final String myProp2;
        // A bunch of other String properties
    
        public MyStructure(String myProp1, String myProp2 /* All other properties here */) {
            this.myProp1 = myProp1;
            this.myProp2 = myProp2;
            // All other properties set there
        }
    
        public String getMyProp1() { ... }
        public String getMyProp2() { ... }
        // All other getters
    }
    
    

    At this point, one realizes String are themselves immutable, which leads to the second proposal, which again save more lines of code:

    public class MyStructure {
    
        public final String myProp1;
        public final String myProp2;
        // A bunch of other String properties
    
        public MyStructure(String myProp1, String myProp2 /* All other properties here */) {
            this.myProp1 = myProp1;
            this.myProp2 = myProp2;
            // All other properties set there
        }
    }
    
    

    Given that attributes are final and that Java String are immutable, the class still safe against unwanted changes. Note that it works only because String are immutable by definition in Java. With a Date property, it wouldn’t work as Dates are mutable.

    The same can be done with stateless services, with embedded services that needs to be accessed from children classes. There’s no need to have a getter:

    public class MyService {
    
        // Can be accessed from children classes
        protected final EmbeddedService anotherService;
    
        public MyService(EmbeddedService anotherService) {
            this.anotherService = anotherService;
        }
    }
    
    

    Note this approach is 100% compatible with for Dependency Injection, either Spring or CDI.

    Now, you cannot imagine the amount of back and forth comments this simple review caused. Why? Because even if that makes sense from a coding point of view, it’s completely different from what we usually do.

    In that case, laziness and IDEs don’t serve us well. The latter make it too easy to create accessors. I’m pretty sure if we had to code getters and setters by hand, the above proposals would be more in favor.

    This post could easily have been titled “Don’t let habits get the best of you”. The lesson here is to regularly challenge how you code, even for simple easy stuff. There might be better alternatives after all.

    Categories: Java Tags: good practice
  • GitLab, the overlooked Git solution in the cloud

    When one thinks about hosting one’s Git repository online, one’s first choice is just Github, no questions asked. It’s so successful that it has become the de facto standard of Git solutions in the cloud. It’s so well-entrenched that developers are advised to use it as their portfolio. At first glance, Github has it all: public repositories, group collaboration, metrics, page hosting, on-premise install option, etc.

    Major players host their Open-Source code on Github: Spring, Netflix, Google, SAP, etc. I’m also a huge Github user. I use it to share my code for my blog article and also when speaking at conferences when live-coding. Another great feature of Github is Github Pages. For those not familiar with Pages, it’s a great way to host your static - or Markdown-based, websites. In the later case, Github takes automatically care of the Markdown - HTML conversion. Here’s an example of mine: the Github repository and its child moorevaadin.com website.

    However, I found myself more and more frustrated with Github’s limitations. I’m not complaining since I don’t pay anything but stating a fact. It started very simply: non-paying users can only have public repositories, yet, sometimes, I need to host code that I don’t want to keep to myself. For that, I used Atlassian’s Bitbucket. Non-paying users of Bitbucket enjoy 5 private repositories. That’s not a lot, but that was enough for my needs.

    Recently, I needed to host another blog on Github Pages. However, I wanted it to use Asciidoctor format instead of Markdown. I’ve used Markedown exclusively for my last book and it has nothing regarding linking to code snippets. Basically, it’s just copy-paste and you have to keep everything in sync yourself. On the contrary, Asciidoctor has such a feature, either by line-number or by tagging in the original source code. Good news, Asciidoctor offers a Jekyll plugin. Bad news, this isn’t supported by Github out-of-the-box. Github will render Asciidoctor files in HTML when browsing Github but will not generate the website as with Markdown.

    Of course, there are workarounds - or to be specific, at least one that I know of. As the Github Pages build is private, you can plug in the Travis build tool and hack around it. I stumbled upon this article that describes how to do it. As you can see, this unfortunately is not trivial. I was really disappointed to have to sign in to Travis just to achieve that and started looking for alternatives.

    It didn’t take me long to find GitLab, another Git cloud solution. Where Github needs a dedicated third-party build tool, GitLab has its own tool, fully integrated. Even better, generation of the site just takes this very short file:

    And this week, I just discovered that Github cannot protect branches - especially master, against direct pushes. What it can do is prevent force pushes and/or check for a number of build statuses before merging. However, Gitlab offers that option. Finally, it also provides unlimited private repositories for an unlimited of users.

    Probably, there are many more options to explore on GitLab. Be sure I’ll do that in the following weeks. And I’d advise you to do that too, you might find something missing in more well-known solutions.

    Categories: Technical Tags: gitgithubgitlabprovider
  • Code improvements with Kotlin

    Kotlin logo

    This week, I tried to improve my pet Android application developed in Kotlin. As I was very new to Kotlin when I started it, most of the code just looks like Java written in Kotlin.

    Starting simple

    Here’s one such snippet, that needs to initialize both a template message and its argument:

    val messageTemplate: String
    val params: Array<Any>
    
    when (shownCount) {
        0 -> {
            messageTemplate = noItem
            params = arrayOf<Any>()
        }
    
        1 -> {
            messageTemplate = itemShowSingle
            params = arrayOf<Any>(totalCount)
    	}
    
        else -> {
            messageTemplate = itemShowCount
            params = arrayOf(shownCount, totalCount)
        }
    }
    
    Pair
    Kotlin versions after M3 don't offer Tuple anymore, but specialized versions like Pair and Triple in the stdlib. Also, the to() extension function can create such pairs on the fly, without resorting to the constructor.
    Destructuring declarations
    Kotlin allows to initialize multiple variables at once when the function returns a Pair, a Triple or any data class for that matter.

    This is the new improved code:

    val (messageTemplate, params) = when (shownCount) {
        0 -> noItem to arrayOf<Any>()
        1 -> itemShowSingle to arrayOf<Any>(totalCount)
        else -> itemShowCount to arrayOf(shownCount, totalCount)
    }
    

    stdlib also known as Kotlin's toolbelt

    A common task in Android is to send data to the SQLite database through ContentValues instances. Naive Java ports look like the following snippet:

    val taskValues = ContentValues()
    taskValues.put(T_NAME_COL, task.name)
    taskValues.put(T_DESC_COL, task.description)
    taskValues.put(T_PRIO_COL, task.priority)
    taskValues.put(T_DONE_COL, if (task.done) 1 else 0)
    taskValues.put(T_LIST_COL, list.id)
    
    if (task.imagePath != null) {
        taskValues.put(T_IMG_COL, task.imagePath.toString())
    }
    

    Kotlin’s stdlib provides a number of interesting functions.

    apply()
    apply() is an extension function set on Any type. It accepts a null-returning function as a parameter, applies it to the receiver and return the later. Note that in the scope of the lambda, this is the receiver.
    let()
    let() is another extension function set on Any type. It accepts a transforming function as a parameter and calls it with the receiver as the parameter.
    Null-safe call operator
    The .? operator will only called the right-hand operand if the left-hand operand is not null. It's Kotlin's idiomatic way for null checking

    Using them in combination gives the following code:

    val taskValues = ContentValues().apply {
        put(T_NAME_COL, task.name)
        put(T_DESC_COL, task.description)
        put(T_PRIO_COL, task.priority)
        put(T_DONE_COL, if (task.done) 1 else 0)
        put(T_LIST_COL, list.id)
        task.imagePath?.let { put(T_IMG_COL, it.toString()) }
    }
    

    Going further

    Another common Android task it to read data stored in UI components:

    val id = nameView.tag as Long?
    
    if (id != null) {
        task.id = id
    }
    
    Safe cast
    Casts are handled in Kotlin with the as operator. However, nullable and non-nullable types don't belong to the same hierarchy. Hence, if one casts null to a non-nullable type, a ClassCastException will be thrown at runtime. To avoid that, us the as? smart cast operator.

    Using let() and the .? operator in conjunction with smart cast produces the next improvement:

    (nameView.tag as? Long)?.let { task.id = it }
    

    The whole shebang

    The final common snippet is related to querying SQLite databases. Basically, the usual flow is to create the object, create the cursor, iterate over it to read values and set object’s attributes from them. It looks like this:

    fun findById(id: Long): Task {
        val cursor = readableDatabase.rawQuery("SELECT A LOT FROM TABLE", arrayOf(id.toString()))
        cursor.moveToFirst()
        val name = cursor.getString(1)
        val description = cursor.getString(2)
        val imagePath = cursor.getString(3)
        val task = Task(name, description)
    
        if (!cursor.isNull(4)) {
            val date = cursor.getLong(4)
            task.alarm = Date(date)
        }
    
        cursor.close()
        task.id = id
    
        if (imagePath != null) {
            task.imagePath = Uri.parse(imagePath)
        }
        
        return task
    }
    
    Local functions
    Methods in Java are about visibility and scoping. Basically, if one wants a method not reused in other classes, one sets the private visibility. If this method is used only in another method, it just pollutes the class namespace. Embedded functions are a way to declare a function inside another one to avoid this pollution. Kotlin (as well as Scala) allows that.
    with()
    Another useful function from stdlib is with(). Available on any type, it takes 2 parameters: the first is the receiver, the second a transforming function and calls the later on the former.

    Combining those with some of the above features can improve the code a lot:

     fun findById(id: Long): Task {
    
        fun toTask(cursor: Cursor): Task {
            with(cursor) {
                moveToFirst()
                val name = getString(1)
                val description = getString(2)
                val imagePath = getString(3)
                return Task(name, description).apply {
                    if (!isNull(4)) {
                        val date = getLong(4)
                        val alarm = Date(date)
                        this.alarm = alarm
                    }
    
                    this.id = id
                    imagePath?.let { this.imagePath = Uri.parse(it) }
                    close()
                }
            }
         }
    
        return readableDatabase.rawQuery(
                "SELECT A_LOT FROM TABLE",
                arrayOf(id.toString())).let { toTask(it) }
    }
    

    Conclusion

    Learning a new programming language is easy: many books promise to do that in 21 days. The hard part is how to write idiomatic code in that new language. This is a long and arduous journey, that needs a lot of reading such idiomatic code, writing “bad” code yourself and improving it over the course of many iterations.

    Categories: Development Tags: androidkotlin
  • Maze-walking algorithm

    Last week, a colleague pointed out to my team an online developer recruitment challenge. As I find it fun and there was no need to disclose one’s email, I decided to try, just to check if I could to it.

    The problem is quite simple but not easy: consider a rectangular maze of finite size. One has to find a specific cell on the board - the exit, starting from the origin. One has 2 move options: one cell at a time in one of the 4 cardinal points or jumping to any previously visited cell. Of course, it wouldn’t be a maze if there was no obstacle: each cell provides information on the 4 adjacent cells, whether it’s unvisited, blocked by a wall or already explored. There’s one final constraint: each maze is alive for a finite amount of time. If the end cell is not reached after the timeout, it’s a failure.

    After reading the page dedicated on maze solving algorithms on Wikipedia, I decided to implement the wall follower. It’s very simple, basically, you always follow the left (or right) wall.

    My first implementation did just that. The problem with this solution is once a dead end has been reached - a cell with one visited direction and all other blocked, one has to move back again cell by cell. This implementation always failed because of the timeout.

    I tried to be smarter for my second try. Instead of going back cell by cell, I thought about jumping to the last cell which offered a choice between at least 2 unexplored adjacent cells. In order to do that, I put such cells on a stack when I moved in one. When in a dead end, I just need to pop the top cell on the stack and jump to it in one single move. It’s queried again and updated as one less direction is considered unexplored and the process continues.

    It happened to be a good enough solution: I succeeded 2 times (and failed a few times too), got both the secret message and the URL of the page you could apply to. Too bad, it’s in Canada but it was fun. To make it even more fun, I developed in Kotlin with the Fuel library.

    Categories: Development Tags: algorithm