• 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 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 morevaadin.com. 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.

    Sequence diagram

    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
    2. UnsupportedBrowserHandler: returns a specific message if the browser is not supported by Vaadin
    3. UidlRequestHandler: handles RPC communication between client and server
    4. FileUploadHandler: handles file uploads achieved with the FileUpload component
    5. HeartbeatHandler: handles heartbeat requests
    6. PublishedFileHandler
    7. 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:

    Class diagram

    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 class makes it very clear that it’s quite hard to extend. Besides, it delegates HTML generation to the JSoup 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?
    2. Rewrite a large portion of the BootstrapHandler and add it before the BootstrapHandler in the handlers sequence
    3. Be lazy and apply Ockham’s razor: just use a simple AOP 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.

    @Aspect
    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:

    spring.aop.proxy-target-class=true

    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"?>
    <aspectj>
      <aspects>
        <aspect name="ch.frankel.blog.bootvaadinkotlin.UpdateLangAspect" />
      </aspects>
    
      <weaver options="-XnoInline -Xlint:ignore -verbose -showWeaveInfo">
        <include within="org.jsoup.nodes.Document" />
        <include within="ch.frankel.blog.bootvaadinkotlin.UpdateLangAspect" />
      </weaver>
    </aspectj>

    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.

    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <configuration>
        <agent>${settings.localRepository}/org/aspectj/aspectjweaver/1.8.8/aspectjweaver-1.8.8.jar</agent>
      </configuration>
    </plugin>

    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
  • Feedback on the Josephus problem

    My last week article was about the solving the Josephus problem in Kotlin. For ease of comparison, here’s the version I wrote originally:

    class Soldier(val position: Int) {
    
        var state = State.Living
        lateinit var next: Soldier
    
        fun suicide() {
            state = State.Dead
        }
    
        fun isDead() = state == State.Dead
    }
    
    enum class State {
        Living, Dead
    }
    
    class Circle(private val size: Int, private val step: Int) {
    
        private val first = Soldier(0)
    
        init {
            var person = first
            while (person.position < size - 1) {
                person = createNext(person)
            }
            val last = person
            last.next = first
        }
    
        private fun createNext(soldier: Soldier): Soldier {
            val new = Soldier(soldier.position + 1)
            soldier.next = new
            return new
        }
    
        fun findSurvivor(): Soldier {
            var soldier: Soldier = first
            var numberOfDead = 0
    
            while (numberOfDead < size - 1) {
                var count: Int = 0
                while (count < step) {
                    soldier = nextLivingSoldier(soldier)
                    count++
                }
                soldier.suicide()
                numberOfDead++
            }
            return nextLivingSoldier(soldier)
        }
    
        private fun nextLivingSoldier(soldier: Soldier): Soldier {
            var currentSoldier = soldier.next
            while (currentSoldier.isDead()) {
                currentSoldier = currentSoldier.next
            }
    
            return currentSoldier
        }
    }

    The post ended with an open question: was the code the right way to do it? In particular:

    • Is the code idiomatic Kotlin?
    • Lack of for means using while with var
    • Too many mutability (var) for my own liking

    I’ve received great feedback from the community on many different channels, including Ilya Ryzhenkov from JetBrains, Cédric Beust, Peter Somerhoff and Gaëtan Zoritchak. Thanks guys!

    I think the most interesting is this one, very slightly modified from the original Gist by Gaëtan:

    class Soldier(val position: Int, var state:State = State.Living) {
    
        fun suicide() {
            state = State.Dead
        }
    
        fun isAlive() = state == State.Living
    }
    
    enum class State {
        Living, Dead
    }
    
    class Circle(val size: Int, val step: Int) {
    
        val soldiers = Array( size, {Soldier(it)}).toList()
    
        fun findSurvivor(): Soldier {
            var soldier = soldiers.first()
            (2..size).forEach {
                (1..step).forEach {
                    soldier = soldier.nextLivingSoldier()
                }
                soldier.suicide()
            }
            return soldier.nextLivingSoldier()
        }
    
       tailrec private fun Soldier.nextLivingSoldier():Soldier =
           if (next().isAlive())
               next()
           else
               next().nextLivingSoldier()
    
        private fun Soldier.next() = soldiers.get(
            if (position == size - 1)
                0
            else
                position + 1
        )
    }

    I like this code a lot because it feels more Kotlin-esque. Improvements are many.

    • The code is shorter without any loss of readability
    • It’s entirely functional, there’s only a single var involved:
      • the 2 while loops with their associated var counter have been replaced by simple forEach on Int ranges.
      • Chaining Soldier instances is not handled in the Soldier class itself through the next() method but by the containing Circle. Thus, a simple backing array can store them and there’s no need for custom code with mutable variables.
    • The recursive nextLivingSoldier() function has been "annotated" with tailrec in order for the compiler to run its optimization magic.
    • The Soldier class doesn’t know about its container Circle size, so functions using it have been moved inside the Circle class as extension functions to the Soldier class. This is a great usage of Kotlin’s extension functions.

    This experience reinforced my belief that learning a language by just reading about it is not enough. To truly make it yours, steps should be those:

    1. obviously, learn the syntax of the language - and its API,
    2. code a solution or an app with this language,
    3. ask for feedback,
    4. read, analyze and understand the feedback,
    5. rinse and repeat.
    Categories: Development Tags: algorithmkotlin
  • Solving the Josephus problem in Kotlin

    I recently stumbled upon a post telling about the Josephus problem and trying to solve it in different scripting languages. For the sake of brevity, here’s the problem (taken from the referenced post):

    Flavius Josephus was a roman historian of Jewish origin. During the Jewish-Roman wars of the first century AD, he was in a cave with fellow soldiers, 40 men in all, surrounded by enemy Roman troops. They decided to commit suicide by standing in a ring and counting off each third man. Each man so designated was to commit suicide…​Josephus, not wanting to die, managed to place himself in the position of the last survivor. In the general version of the problem, there are n soldiers numbered from 1 to n and each k-th soldier will be eliminated. The count starts from the first soldier. What is the number of the last survivor?

    It seemed like a good challenge to test my building Kotlin skills. Here’s the solution I’ve come up with. First, the test class, using TestNG and a data provider - it’s the perfect use-case:

    class JosephusTest {
    
        @DataProvider
        fun data(): Array<Array<Int>> {
            return arrayOf(
                    arrayOf(2, 1, 0),
                    arrayOf(3, 1, 0),
                    arrayOf(10, 1, 0),
                    arrayOf(3, 2, 0),
                    arrayOf(4, 2, 1)
            )
        }
    
        @Test(dataProvider = "data")
        fun circle_of_size_and_step_should_survive_position(size: Int, step: Int, expectedPosition: Int) {
            val circle = Circle(size, step)
            val survivor = circle.findSurvivor()
            assertEquals(survivor.position, expectedPosition)
        }
    }

    Now, the code:

    class Soldier(val position: Int) {
    
        var state = State.Living
    
        lateinit var next: Soldier
    
        fun suicide() {
            state = State.Dead
        }
    
        fun isDead() = state == State.Dead
    }
    
    enum class State {
        Living, Dead
    }
    
    class Circle(private val size: Int, private val step: Int) {
    
        private val first = Soldier(0)
    
        init {
            var person = first
            while (person.position < size - 1) {
                person = createNext(person)
            }
            val last = person
            last.next = first
        }
    
        private fun createNext(soldier: Soldier): Soldier {
            val new = Soldier(soldier.position + 1)
            soldier.next = new
            return new
    
        }
    
        fun findSurvivor(): Soldier {
            var soldier: Soldier = first
            var numberOfDead = 0
            while (numberOfDead < size - 1) {
                var count: Int = 0
                while (count < step) {
                    soldier = nextLivingSoldier(soldier)
                    count++
                }
                soldier.suicide()
                numberOfDead++
            }
            return nextLivingSoldier(soldier)
    
        }
    
        private fun nextLivingSoldier(soldier: Soldier): Soldier {
            var currentSoldier = soldier.next
            while (currentSoldier.isDead()) {
                currentSoldier = currentSoldier.next
            }
            return currentSoldier
        }
    }

    This code works fine and the tests are successful.

    However, while trying to code the solution, I realized that there were no data-structure implementing circular linked lists neither in Java nor in Kotlin. I had thus to implement my own circular data-structure, but without implementing common collection features.

    Now, my problem with the above code is that while the Soldier class looks fine by me, the Circle class doesn’t. There are too many var in Circle and it feels too much like imperative programming. The lack of for(;;) in Kotlin forces me to use a while with an outside variable - twice: count and numberOfDead.

    I’ve been thinking that I could improve the situation by changing the data-structure. I just don’t know how…​ Now, Kotlin and FP gurus, do you have any proposal?

    Categories: Development Tags: algorithmkotlin
  • The sad state of developer interviews

    Recruiting is a complex process, and recruiting developers even more so. In this post, I will focus solely on the interviewing part (and leave the rant about recruiters who are paid 1 year of the candidate’s salary to just match buzzwords for another time).

    I recently stumbled upon an article about interview questions, again, telling you about "right" answers for such and such questions. There are plenty of such articles on the World Wide Web, full-fledged sites dedicated to this topic and a couple of books too. A few of them are "free", the others paying. But let’s be straightforward: I believe it to be complete and utter crap. Now that it’s said, let me develop.

    First, a little explanation about my experience in such matters is in order. I’ve been working around 15 years in the software industry as a consultant, so that I’ve been interviewed a lot by employers and customers alike. Also, I’ve been on the other side - technical recruiting, either alone or as a part of a recruiting task force.

    Here are some examples of the situations I’ve experienced as an candidate in no particular order:

    • The lightweight interview:
      • "Do you know this?"
      • "Yes"
      • "And that?"
      • "No, but I can learn"
    • Multiple-choice questions on a very specific subject (EJB). Interestingly, albeit passed with not a bad score (28/30 if I remember well), I was not chosen
    • Multiple-choice questionnaire. Then, on some questions, I asked about the context because different answers could apply but the person who made me pass the test couldn’t answer.
    • Multiple-choice questionnaire again. But a question was incorrect and I told the recruiter about it. In the end, I was recruited…​ then my first task as a new employee was to browse through all questions to find other potential errors.

    IMHO, there’s a 0 - let me emphasize that, zero correlation between the ability to answer correctly on a multiple-choice questions kind of test and the ability to be an effective programmer. As additional evidence, as a teacher, I also used this kind of test as an exam once and that was an great disappointment, good students failing miserably. May I also mention a certified Java X programmer - certification is based on this kind of test, not being able to explain the overall architecture of his latest project?

    At least, the chit-chat kind of interview doesn’t over-promise. It’s generally friendly and based on human interactions. The key here is for the candidate to be as truthful as possible. I always tried to do that, and it worked every time. Why would I tell something which is not true? Otherwise, at some point in the future, I would be exposed as a fraud. I’d have lost time as well as my employer, and my reputation would be tarnished. However, some people don’t think likewise so interviewers have to take precautions.

    In the end, the only interview method that does work is to put the candidate in the exact same situation he would be during regular work: in front of a computer and to make him solve a problem. Sure, it’s still miles away from a real situation but it’s hard to get closer. There a lot of such code-related problems available out there, but you should cook your own. As above, you don’t want candidates to rehearse for a specific problem but to show you what they can.

    And yet, despite everything, some recruiters - if not most, still prefer to go the multiple-choice questions road. And candidates read and sometimes are willing to pay to rehearse for such kind of interviews. Why is that, then? Well, my guess is that because most people still don’t understand software development, don’t know how candidates can be evaluated and thus go the only way they know. As I understand, at least Americans have a bias toward tests because they’ve been used to them in public schools (please correct me if I’m wrong); Europeans have no such excuses.

    However, this is not limited to recruiting. It seems managers at all levels prefer wrong information to no information at all. Hell, it’s even worse because most of them know it’s wrong, but they are happy to pass it to the upper echelon nonetheless - that’s their job. Come to think of it, this behavior is very widespread. Take time-sheeting for example: people cannot be totally precise, so let’s assume 5% uncertainty. Readers with scientific background know that uncertainties add. So, a company with 20 persons has 100% uncertainty on their time-sheets. Another golden example for preferring wrong information to no information is project planning. Everybody know that in most cases, it’s a lot of bullshit, but yeah, everyone goes along with the flow.

    Recruiting, planning, timesheeting…​ Sad state, isn’t it?

    Categories: Miscellaneous Tags: interviewrecruiting
  • Log management in Spring Boot

    Logging is for sure not a glamorous subject, but it’s a critical one - at least for DevOps and Ops teams. While there are plenty of material on the Web describing how to change your ASCII banner, there is not much on how to efficiently manage the log output.

    By default, Spring Boot will output log on the console and not use any file at all.

    However, it’s possible to tell Spring Boot to log in an output file. At the simplest level, the path where Spring Boot will put the spring.log file can be easily configured in the application.properties under the logging.path key:

    logging.path=/var/log

    Note that another alternative is to use the logging.file key in order to not only set the file path but also the file name.

    logging.file=/var/log/myapp.log

    While this works very well for development purposes, it’s not an acceptable process for the Ops team to unzip the final jar, update the application.properties file and repackage it - this for each and every different environment.

    Spring Boot allows to override the value set in the packaged file (if any) on the command-line as a standard system property when launching the jar:

    java -jar -Dlogging.path=/tmp  myapp.jar

    Finally, it’s also possible to override this value when invoking the Spring Boot Maven plugin on the command line. However, directly using the system property doesn’t work for the plugin will spawn another JVM. One has to use the run.jvmArguments system property and delegate it the wanted value:

    mvn spring-boot:run -Drun.jvmArguments="-Dlogging.path=/tmp"

    Note that this works for every available property!

    Categories: Java Tags: loggingspring boot
  • Designing your own Spring Boot starter – part 2

    In the last post, I tried to describe the internal working of Spring Boot starter. It’s now time to develop our own!

    As an example, we will use XStream, a no-fluff just-stuff XML/JSON (de)serializer offered by Thoughtworks. Readers who only use JAXB and Jackson are advised to have a look at XStream, it’s extremely efficient and its API is quite easy to use.

    As seen in our last post, the entry-point of a starter lies in the META-INF/spring.factories file. Let’s create such a file, with the adequate content:

    org.springframework.boot.autoconfigure.EnableAutoConfiguration=ch.frankel.blog.xstream.XStreamAutoConfiguration

    Now, let’s create the class referenced above. As we have seen previously, an auto-configuration class is just a regular configuration class. It’s ok to keep it empty for the time being.

    @Configuration
    public class XStreamAutoConfiguration {}

    XStream is build around the aptly-named XStream class, which is an entry-point into its serialization features. Thoughtworks designed it to avoid static methods, so that you need an XStream instance. Creating an instance is a boring repetitive task with no value: it looks like it’s a perfect target for a Spring bean. Let’s create this instance in the auto-configuration class as a singleton bean so that client applications can use it. Our configuration class becomes:

    @Configuration
    public class XStreamAutoConfiguration {
    
        @Bean
        public XStream xstream() {
            return new XStream();
        }
    }

    There are other alternatives to the XStream no-args constructor documented on XStream’s website e.g. one for StaX, another for JSON, etc. Our starter should allow client applications to use their own instance, thus creating it only if there are none provided in the context. That sounds a lot like a conditional on missing bean:

    @Configuration
    public class XStreamAutoConfiguration {
    
        @Bean
        @ConditionalOnMissingBean(XStream.class)
        public XStream xstream() {
            return new XStream();
        }
    }

    XStream is based on converters, a way to convert from one typed value to a JSON/XML formatted string (and the other way around). There are a lot of out-of-the-box pre-registered converters but clients can register their own. In that case, it should be possible to provide them in the context so that they get registered with the provided instance.

    To do that, create a @Bean method that takes both an XStream instance and a collection of converters as injected arguments. This method should only be called if there’s at least one Converter instance in the context. This can easily be configured with the @ConditionalOnBean annotation.

    @Bean
    @ConditionalOnBean(Converter.class)
    public Collection<Converte> converters(XStream xstream, Collection<Converter> converters) {
        converters.forEach(xstream::registerConverter);
        return converters;
    }

    At this point, any custom converter provided in the Spring context by client applications will be registered in the XStream instance.

    This concludes this post on creating Spring Boot starters. It’s quite easy and straightforward! Before going forward with your own, don’t forget to check existing starters, there are already quite a lot provided out-of-the-box and by the community.

    Categories: Java Tags: spring boot
  • Designing your own Spring Boot starter - part 1

    Since its release, Spring Boot has been a huge success: it boosts developers productivity with its convention over configuration philosophy. However, sometimes, it just feels too magical. I have always been an opponent of autowiring for this exact same reason. And when something doesn’t work, it’s hard to get back on track.

    This is the reason why I wanted to dig deeper into Spring Boot starter mechanism - to understand every nook and cranny. This post is the first part and will focus on analyzing how it works. The second part will be a case study on creating a starter.

    spring.factories

    At the root of every Spring Boot starter lies the META-INF/spring.factories file. Let’s check the content of this file in the spring-boot-autoconfigure.jar. Here’s an excerpt of it:

    ...
    
    # Auto Configure
    org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
    org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\
    org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\
    org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,\
    org.springframework.boot.autoconfigure.MessageSourceAutoConfiguration,\
    org.springframework.boot.autoconfigure.PropertyPlaceholderAutoConfiguration,\
    org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration,\
    ...

    Now let’s have a look at their content. For example, here’s the JpaRepositoriesAutoConfiguration class:

    @Configuration
    @ConditionalOnBean(DataSource.class)
    @ConditionalOnClass(JpaRepository.class)
    @ConditionalOnMissingBean({ JpaRepositoryFactoryBean.class, JpaRepositoryConfigExtension.class })
    @ConditionalOnProperty(prefix = "spring.data.jpa.repositories", name = "enabled",
        havingValue = "true",  matchIfMissing = true)
    @Import(JpaRepositoriesAutoConfigureRegistrar.class)
    @AutoConfigureAfter(HibernateJpaAutoConfiguration.class)
    public class JpaRepositoriesAutoConfiguration {}

    There are a couple of interesting things to note:

    1. It’s a standard Spring @Configuration class
    2. The class contains no "real" code but imports another configuration - JpaRepositoriesAutoConfigureRegistrar, which contains the "real" code
    3. There are a couple of @ConditionalOnXXX annotations used
    4. There seem to be a order dependency management of some sort with @AutoConfigureAfter

    Points 1 and 2 are self-explanatory, point 4 is rather straightforward so let’s focus on point 3.

    @Conditional annotations

    If you didn’t start to work with Spring yesterday, you might know about the @Profile annotation. Profiles are a way to mark a bean-returning method as being optional. When a profile is activated, the relevant profile-annotated method is called and the returning bean contributed to the bean factory.

    Some time ago, @Profile looked like that:

    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.TYPE)
    public @interface Profile {
        String[] value();
    }

    Interestingly enough, @Profile has been rewritten to use the new @Conditional annotation:

    @Retention(RetentionPolicy.RUNTIME)
    @Target({ElementType.TYPE, ElementType.METHOD})
    @Documented
    @Conditional(ProfileCondition.class)
    public @interface Profile {
        String[] value();
    }

    Basically, a @Conditional annotation just points to a Condition. In turn, a condition is a functional interface with a single method that returns a boolean: if true, the @Conditional-annotated method is executed by Spring and its returning object added to the context as a bean.

    Condition class diagram

    There are a lot of conditions available out-of-the-box with Spring Boot:

    Condition Description

    OnBeanCondition

    Checks if a bean is in the Spring factory

    OnClassCondition

    Checks if a class is on the classpath

    OnExpressionCondition

    Evalutates a SPeL expression

    OnJavaCondition

    Checks the version of Java

    OnJndiCondition

    Checks if a JNDI branch exists

    OnPropertyCondition

    Checks if a property exists

    OnResourceCondition

    Checks if a resource exists

    OnWebApplicationCondition

    Checks if a WebApplicationContext exists

    Those can be combined together with boolean conditions:

    Condition Description

    AllNestedConditions

    AND operator

    AnyNestedConditions

    OR operator

    NoneNestedCondition

    NOT operator

    Dedicated @Conditional annotations point to those annotations. For example, @ConditionalOnMissingBean points to the OnBeanCondition class.

    Time to experiment

    Let’s create a configuration class annotated with @Configuration.

    The following method will run in all cases:

    @Bean
    public String string() {
        return "string()";
    }

    This one won’t, for java.lang.String is part of Java’s API:

    @Bean
    @ConditionalOnMissingClass("java.lang.String")
    public String missingClassString() {
        return "missingClassString()";
    }

    And this one will, for the same reason:

    @Bean
    @ConditionalOnClass(String.class)
    public String classString() {
        return "classString()";
    }

    Analysis of the previous configuration

    Armed with this new knowledge, let’s analyze the above JpaRepositoriesAutoConfiguration class.

    This configuration will be enabled if - and only if all conditions are met:

    @ConditionalOnBean(DataSource.class)

    There’s a bean of type DataSource in the Spring context

    @ConditionalOnClass(JpaRepository.class)

    The JpaRepository class is on the classpath i.e. the project has a dependency on Spring Data JPA

    @ConditionalOnMissingBean

    There are no beans of type JpaRepositoryFactoryBean nor JpaRepositoryConfigExtension in the context

    @ConditionalOnProperty

    The standard application.properties file must contain a property named spring.data.jpa.repositories.enabled with a value of true

    Additionally, the configuration will run after HibernateJpaAutoConfiguration (if the latter is referenced).

    Conclusion

    I hope I demonstrated that Spring Boot starters are no magic. Join me next week for a simple case study.

    Categories: Java Tags: spring boot
  • Why you shouldn't trust the HTML password input

    This week, I wanted to make a simple experiment. For sure, all applications we develop make use of HTTPS to encrypt the login/password but what happens before?

    Let’s say I typed my login/password but before sending them, I’m called by my colleague and I leave my computer open. My password is protected by the HTML password input, right? It shows stars instead of the real characters. Well, it’s stupidly easy to circumvent this. If you use a developer workstation and have developer tools on your browser, just live edit the page and change type="password" to type="text". Guess what? It works and displays the password in clear text. You have been warned!

    Source view of the password input
    Categories: Development Tags: HTMLsecurity
  • The Java Security Manager: why and how?

    Generally, security concerns are boring for developers. I hope this article is entertaining enough for you to read it until the end since it tackles a very serious issue on the JVM.

    Quizz

    Last year, at Joker conference, my colleague Volker Simonis showed a snippet that looked like the following:

    public class StrangeReflectionExample {
    
        public Character aCharacter;
    
        public static void main(String... args) throws Exception {
            StrangeReflectionExample instance = new StrangeReflectionExample();
            Field field = StrangeReflectionExample.class.getField("aCharacter");
            Field type = Field.class.getDeclaredField("type");
            type.setAccessible(true);
            type.set(field, String.class);
            field.set(instance, 'A');
            System.out.println(instance.aCharacter);
        }
    }

    Now a couple of questions:

    1. Does this code compile?
    2. If yes, does it run?
    3. If yes, what does it display?

    Answers below.

    This code compiles just fine. In fact, it uses the so-called reflection API (located in the java.lang.reflect package) which is fully part of the JDK.

    Executing this code leads to the following exception:

    Exception in thread "main" java.lang.IllegalArgumentException:
            Can not set java.lang.String field ch.frankel.blog.securitymanager.StrangeReflectionExample.aCharacter
                to java.lang.Character
    	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
    	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
    	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
    	at java.lang.reflect.Field.set(Field.java:764)
    	at ch.frankel.blog.securitymanager.StrangeReflectionExample.main(StrangeReflectionExample.java:15)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.lang.reflect.Method.invoke(Method.java:497)
    	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)

    So, despite the fact that we defined the type of the aCharacter attribute as a Character at development time, the reflection API is able to change its type to String at runtime! Hence, trying to set it to 'A' fails.

    Avoiding nasty surprises with the Security Manager

    Reflection is not the only risky operation one might want to keep in check on the JVM. Reading a file or writing one also belong to the set of potentially dangerous operations. Fortunately, the JVM has a system to restrict those operations. Unfortunately, it’s not set by default.

    In order to activate the SecurityManager, just launch the JVM with the java.security.manager system property i.e. java -Djava.security.manager. At this point, the JVM will use the default JRE policy. It’s configured in the file located at %JAVA_HOME%/lib/security/java.policy (for Java 8). Here’s a sample of this file:

    grant codeBase "file:${java.ext.dirs}/*" {
            permission java.security.AllPermission;
    };
    
    grant {
            permission java.lang.RuntimePermission "stopThread";
            permission java.net.SocketPermission "localhost:0", "listen";
            permission java.util.PropertyPermission "java.version", "read";
            permission java.util.PropertyPermission "java.vendor", "read";
            ...
    }

    The first section - grant codeBase, is about which code can be executed; the second - grant, is about specific permissions.

    Regarding the initial problem regarding reflection mentioned above, the second part is the most relevant. One can read the source of the AccessibleObject.setAccessible() method:

    SecurityManager sm = System.getSecurityManager();
    if (sm != null) sm.checkPermission(ACCESS_PERMISSION);
    setAccessible0(this, flag);

    Every sensitive method to a Java API has the same check through the Security Manager. You can verify that for yourself in the following code:

    • Thread.stop()
    • Socket.bind()
    • System.getProperty()
    • etc.

    Using an alternate java.policy file

    Using the JRE’s policy file is not convenient when one uses the same JRE for different applications. Given the current micro-service trend, this might not be the case. However, with automated provisioning, it might be more convenient to always provision the same JRE over and over and let each application provides its own specific policy file.

    To add another policy file in addition to the default JRE’s, thus adding more permissions, launch the JVM with:

    java -Djava.security.manager -Djava.security.policy=/path/to/other.policy

    To replace the default policy file with your own, launch the JVM with:

    java -Djava.security.manager -Djava.security.policy==/path/to/other.policy
    Note the double equal sign.

    Configuring your own policy file

    Security configuration can be either based on a:

    Black list

    In a black list scenario, everything is allowed but exceptions can be configured to disallow some operations.

    White list

    On the opposite, in a white list scenario, only operations that are explicitly configured are allowed. By default, all operations are disallowed.

    If you want to create your own policy file, it’s suggested you start with a blank one and then launch your app. As soon, as you get a security exception, add the necessary permission is the policy. Repeat until you have all necessary permissions. Following this process will let you have only the minimal set of permissions to run the application, thus implementing the least privilege security principle.

    Note that if you’re using a container or a server, you’ll probably require a lot of those permissions, but this is the price to pay to secure your JVM against abuses.

    Conclusion

    I never checked policy files in production, but since I never had any complain, I assume the JVM’s policy was never secured. This is a very serious problem! I hope this article will raise awareness regarding that lack of hardening - especially since with the latest JVM, you can create and compile Java code on the fly, leading to even more threats.

    Categories: Java Tags: JVMsecurity
  • Playing with Spring Boot, Vaadin and Kotlin

    It’s no mystery that I’m a fan of both Spring Boot and Vaadin. When the Spring Boot Vaadin add-on became GA, I was ecstatic. Lately, I became interested in Kotlin, a JVM-based language offered by JetBrains. Thus, I wanted to check how I could develop a small Spring Boot Vaadin demo app in Kotlin - and learn something in the process. Here are my discoveries, in no particular order.

    Spring needs non-final stuff

    It seems Spring needs @Configuration classes and @Bean methods to be non-final. As my previous Spring projects were in Java, I never became aware of that because I never use the final keyword. However, Kotlin classes and methods are final by default: hence, you have to use the open keyword in Kotlin.

    @Configuration
    open class AppConfiguration {
    
        @Bean
        @UIScope
        open fun mainScreen() = MainScreen()
    }

    No main class

    Spring Boot applications require a class with a public static void main(String…​ args) method to reference a class annotated with @SpringBootApplication. In general, those two classes are the same.

    Kotlin has no concept of such static methods, but offers pure functions and objects. I tried to be creative by having an annotated object referenced by a pure function, both in the same file.

    @SpringBootApplication
    open class BootVaadinKotlinDemoApplication
    
    fun main(vararg args: String) {
        SpringApplication.run(arrayOf(BootVaadinKotlinDemoApplication::class.java), args)
    }

    Different entry-point reference

    Since the main function is not attached to a class, there’s no main class to reference to launch inside the IDE. Yet, Kotlin creates a .class with the same name as the file name suffixed with Kt.

    My file is named BootVaadinKotlinDemoApplication.kt, hence the generated class name is BootVaadinKotlinDemoApplicationKt.class. This is the class to reference to launch the application in the IDE. Note that there’s no need to bother about that when using mvn spring-boot:run on the command-line, as Spring Boot seems to scan for the main method.

    Short and readable bean definition

    Java syntax is seen as verbose. I don’t think it’s a big issue when its redundancy is very low compared to the amount of useful code. However, in some cases, even I have to admit it’s a lot of ceremony for not much. When of such case is defining beans with the Java syntax:

    @Bean @UIScope
    public MainScreen mainScreen() {
        return new MainScreen();
    }

    Kotlin cuts through all of the ceremony to keep only the meat:

    • No semicolon required
    • No new keyword
    • Block replaced with an equal sign since the body consists of a single expression
    • No return keyword required as there’s no block
    • No return type required as it can easily be inferred
    @Bean @UIScope
    fun mainScreen() = MainScreen()

    Spring configuration files are generally quite long and hard to read. Kotlin makes them much shorter, without sacrificing readability.

    The init block is your friend

    In Java, the constructor is used for different operations:

    1. storing arguments into attributes
    2. passing arguments to the super constructor
    3. other initialization code

    The first operation is a no-brainer because attributes are part of the class signature in Kotlin. Likewise, calling the super constructor is handled by the class signature. The rest of the initialization code is not part of the class signature and should be part of an init block. Most applications do not this part, but Vaadin needs to setup layout and related stuff.

    class MainScreenPresenter(tablePresenter: TablePresenter, buttonPresenter: NotificationButtonPresenter,
            view: MainScreen, eventBus: EventBus) : Presenter<MainScreen>(view, eventBus) {
    
        init {
            view.setComponents(tablePresenter.view, buttonPresenter.view)
        }
    }

    Use the apply method

    Kotlin has a standard library offering small dedicated functions. One of them is apply, defined as inline fun T.apply(f: T.() → Unit): T (source). It’s an extension function, meaning every type will have it as soon as it’s imported into scope. This function requires an argument that is a function and that returns nothing. Inside this function, the object that has been apply-ed is accessible as this (and this is implicit, as in standard Java code). It allows code like this:

    VerticalLayout(button, table).apply {
        setSpacing(true)
        setMargin(true)
        setSizeFull()
    }

    Factor view and presenter into same file

    Kotlin makes code extremely small, thus some files might be only a line long (not counting import). Opening different files to check related classes is useless. Packages are a way to organize your code; I think files might be another way in Kotlin. For example, Vaadin views and presenters can be put into the same file.

    class NotificationButton: Button("Click me")
    class NotificationButtonPresenter(view: NotificationButton, eventBus: EventBus):
      Presenter<NotificationButton>(view, eventBus) { ... }

    Lambdas make great listeners

    As of Java 8, single-method interfaces implemented as anonymous inner classes can be replaced with lambdas. Kotlin offers the same feature plus:

    • it allows to omit parentheses if the lambda is the only argument
    • if the lambda has a single argument, its default name is it and it doesn’t need to be declared

    Both make for a very readable syntax when used in conjunction with the Vaadin API:

    view.addValueChangeListener {
        val rowId = it.property.value
        val rowItem = view.containerDataSource.getItem(rowId)
        eventBus.publish(SESSION, rowItem)
    }
    Still, more complex logic should be put into its own function.
    Categories: JavaEE Tags: kotlinspring bootvaadin