• 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();

    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.


    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)
    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() 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() 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()))
        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)
        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.
    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) {
                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) }
        return readableDatabase.rawQuery(
                "SELECT A_LOT FROM TABLE",
                arrayOf(id.toString())).let { toTask(it) }


    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
  • Experimental: Kotlin and mutation testing

    Since about a year and a half, I do a lot of presentations on Mutation Testing. In those, my point is to show that Code Coverage’s only benefit is that it’s easy to compute but that it’s meaningless - hence Mutation Testing.

    Since some time, I’ve been interested in Kotlin, a language from JetBrains that runs on the JVM. It’s only natural that I wanted to check how Mutation Testing could be applied to the Kotlin language. As Kotlin is too young to have its own dedicated mutation testing tool, I used Pit, a Java dedicated tool. I didn’t expected much, here are my findings.

    I started with a Kotlin-port of my demo project. It has two simple classes and an associated test for each. In the first one, assertion is missing and in the second, the boundary condition of the < operator is not tested. This is the perfect use-case for Mutation Testing. It’s a Maven project, so the command is quite straightforward:

    mvn org.pitest:pitest-maven:mutationCoverage

    Interestingly enough, this works perfectly well, in terms of mutation coverage execution, but also regarding referencing the lines that are the source of the problem.

    I wanted to go further, to use a real project. The Kotlin folks were kind enough to redirect me to KTor, a Kotlin-based web framework. I tried the same command, but limited on a single module - ktor-features/ktor-server-sessions (I have no clue what it does, that is not relevant anyway). Aye, there’s the rub.

    First, Pit cannot correctly parse the generated bytecode at some places:

    PIT >> WARNING : Found more than one mutation similar on same line in a finally block. Can't correct for inlining.

    Worse, there are a lot of timeout errors. Since there’s some threading involved, that’s not really a blocker.

    PIT >> WARNING : Slave exited abnormally due to TIMED_OUT

    For this project, reports are really long, but some errors are really similar to what you’d expect from Java code, for example:

    removed call to kotlin/jvm/internal/Intrinsics::checkParameterIsNotNull → NO_COVERAGE

    Here’s a sample of the report:

    Again, Pit is able to bind the real lines to the problems found. Isn’t life good? If you stop at this point, it probably is. But running Pit on another project - say, ktor-features/ktor-locations fails miserably.

    The class org.jetbrains.ktor.locations.Locations$WhenMappings does not contain a source debug information. All classes must be compiled with source and line number debug information

    It seems using the when construct in Kotlin generates an inner class that doesn’t contain debug information, which Pit need to works its magic. Let’s exclude the offending class and its inner mappings class:

    mvn org.pitest:pitest-maven:mutationCoverage -DexcludedClasses=org.jetbrains.ktor.locations.Locations*

    It works again and produces expected results:

    There are no mutation testing tools for Kotlin (yet), and considering Java ecosystem’s history, there might never be one. However, mutation testing is an invaluable tool to assert the real quality of your tests. Even if Pit is not a perfect match for Kotlin, it would be foolish to discard it.

    Categories: Development Tags: kotlinmutation testingpit
  • Feedback on customizing Vaadin HTML template

    Last week, my post was about how you could customize the default Vaadin HTML template so you could add a lang attribute for example. I didn’t ask for feedback, but I got it anyway, so let’s use the occasion to analyze it.

    First, I must admit that my solution was not Vaadin-esque as I used AOP to get the job done. My friend Matti Tahvonen from the Vaadin team was kind enough to provide not only one but 2 alternatives to my proposal. Thanks Matti!

    Alternative solutions

    The first solution - also the one I got the last, was submitted by AMahdy AbdElAziz:

    Evil but it works and couldn’t be simpler!

    The second solution uses Matti’s own framework - Viritin, to achieve that. I haven’t looked at the framework yet (but it’s in my todo list) so I cannot comment it but here is the snippet:

    The standard Vaadin-esque server-side way is a bit more convoluted:

    However, this one I can analyze and comment :-)

    Flow decomposition

    Note: readers who are more interested in possoble improvements can skip directly to that section.

    The first part is quite easy. It just registers a new SessionInitListener (the proposed code uses a lambda to do that):

    The second part happens when a request is made and Vaadin notices a new session must be created:

    The end of the previous sequence diagram is designed in a generic way in Vaadin. In our specific case, it’s rendered as such:


    I think a couple of improvements can be made.

    • The code is awfully verbose - even using Java 8's lambda
    • Two objects are created each time a session is initialized, the session listener and the bootstrap listener
    • Setting the servlet class as an internal class of the UI sends shiver down my spine. Though I understand this is a Gist, this is unfortunately what you get by using the Vaadin Maven archetype. This is very far from the Single-Responsibility Principle.

    Since my initial example uses both Spring Boot and Kotlin, here’s my version:

    With Spring Boot, I can manage the SessionInitListener as a singleton-scoped Bean. By passing it as a servlet parameter, I can create only a single instance of SessionInitListener and BootstrapListener each. Of course, it’s only possible because the language value is set in stone.

    Thanks to Kotlin, I co-located the overriden servlet class within the configuration file but outside the configuration class. Since the servlet is used only by the configuration, it makes sense to put them together… but not too much.

    Finally, note that SessionInitListener is a functional interface, meaning it has a single method. This single method is the equivalent of a function taking a SessionInitEvent and return nothing. In Kotlin, the signature is (SessionInitEvent) -> Unit. Instead of creating an anonymous inner class, I preferred using the function. It’s not an improvement, but a more functional alternative. At runtime, both alternatives will allocate the same amount of memory.

    The complete source code can be found on Github in the manage-lang branch.

    Categories: JavaEE Tags: kotlinvaadin
  • Customizing Vaadin HTML template

    This week, I had an interesting question on Twitter: “How in Vaadin do you add a lang attribute to the html element?”, like this:

    ```html<html lang="fr">

    While it's quite easy to customize individual components on the page, the outer html tag is outside our control. In this article, I'll describe a possible solution to this problem. Note that I think this is too specialized for <a href="http://morevaadin.com" target="_blank">morevaadin.com</a>. However, this should still be my reference site for all things Vaadin.
    My first (wrong) thought, was that the `html` element is generated by the UI widget client-side. It's not the case - as there's no such widget. In order to find the answer, I had to understand how the framework works. Here's a short summary of the sequence when one makes a request to a Vaadin application.
    <img src="/assets/resources/customizing-vaadin-html-template/sequence.png" class="aligncenter"  height="558" width="827" />
    Basically, the Vaadin Servlet delegates to the Vaadin Service. In turn, the service loops over its internal list of Request Handlers until one of them is able to handle the request. By default, the Vaadin Service registers the following handlers:
    1. ConnectorResourceHandler
    1. UnsupportedBrowserHandler: returns a specific message if the browser is not supported by Vaadin
    1. UidlRequestHandler: handles RPC communication between client and server
    1. FileUploadHandler: handles file uploads achieved with the `FileUpload` component
    1. HeartbeatHandler: handles heartbeat requests
    1. PublishedFileHandler
    1. SessionRequestHandler: delegates in turn to request handlers that have been registered in the session
    This is implemented in `VaadinService.createRequestHandlers()`. However, notice that `VaadinService` is abstract. There's a subtle changed introduced in the concrete `VaadinServletService` subclass that is used. It registers a new request handler - the `ServletBootstrapHandler`, in order for Vaadin to run transparently in both a servlet and a portlet context. In this later case, only a fragment :
    <img src="/assets/resources/customizing-vaadin-html-template/classes.png" class="aligncenter"  height="276" width="533" />
    The servlet boostrap handler is responsible to generate the initial HTML page at the start of the application, including the desired outer `html` tag. Next requests to the application will just update part of the page via AJAX, but the outside HTML won't change. Thus, this is the class that needs to be updated if one wishes to add a `lang` attribute. A quick glance at the <a href="https://vaadin.com/api/com/vaadin/server/BootstrapHandler.html" target="_blank">class</a> makes it very clear that it's quite hard to extend. Besides, it delegates HTML generation to the <a href="http://jsoup.org/" target="_blank">JSoup</a> and more precisely to the `Document.createShell()` static method.
    At this point, you have 3 options:
    1. Forget about it, what is it worth anyway?
    1. Rewrite a large portion of the BootstrapHandler and add it before the BootstrapHandler in the handlers sequence
    1. Be lazy and apply Ockham's razor: just use a simple <abbr title="Aspect-Oriented Programming">AOP</abbr>'s aspect
    In order to be of any use, I chose the latest option. It's quite straightforward and very concise, you only need the following steps.
    Create the aspect itself. Note that I'm using Kotlin to be coherent with the existing project but Java or any other JVM-based language would be the same.
    open class UpdateLangAspect {
        @Pointcut("execution(static * org.jsoup.nodes.Document.createShell(..))")
        fun callDocumentCreateShell(): Unit {}
        @AfterReturning(pointcut = "callDocumentCreateShell()", returning = "document")
        fun setLangAttribute(document: Document): Unit {
            document.childNode(0).attr("lang", "fr")

    As the method to instrument is static, it’s not possible to use simple Spring proxies, but we need AspectJ class instrumentation via LTW. In order to activate it in Spring Boot, I just have to update the application.properties file:


    Also, one has to tell Aspect’s weaver what needs to be instrumented in the META-INF/aop.xml:

    <?xml version="1.0" encoding="UTF-8"?>
        <aspect name="ch.frankel.blog.bootvaadinkotlin.UpdateLangAspect" />
      <weaver options="-XnoInline -Xlint:ignore -verbose -showWeaveInfo">
        <include within="org.jsoup.nodes.Document" />
        <include within="ch.frankel.blog.bootvaadinkotlin.UpdateLangAspect" />

    The first section is about the aspect, the second is about what classes need to be instrumented. Note that weaving section needs also to reference the aspect too.

    Finally, one has to update the POM so that launching the application through the Spring Boot Maven plugin will also use the aspect.


    For sake of completeness, the code is available on Github with the manage-langv1 tag.

    At this point, generating the page will display the desired change. Job done!

    Categories: JavaEE Tags: customizationvaadin