Archive

Posts Tagged ‘IDE’
  • Coping with stringly-typed

    UPDATED on March 13, 2017: Add Builder pattern section

    Most developers have strong opinions regarding whether a language should be strongly-typed or weakly-typed, whatever notions they put behind those terms. Some also actively practice stringly-typed programming - mostly without even being aware of it. It happens when most of attributes and parameters of a codebase are String. In this post, I will make use of the following simple snippet as an example:

    public class Person {
    
        private final String title;
        private final String givenName;
        private final String familyName;
        private final String email;
      
        public Person(String title, String givenName, String familyName, String email) {
            this.title = title;
            this.givenName = givenName;
            this.familyName = familyName;
            this.email = email;
        }
        ...
    }
    

    The original sin

    The problem with that code is that it’s hard to remember which parameter represents what and in which order they should be passed to the constructor.

    Person person = new Person("[email protected]", "John", "Doe", "Sir");
    

    In the previous call, the email and the title parameter values were switched. Ooops.

    This is even worse if more than one constructor is available, offering optional parameters:

    public Person(String givenName, String familyName, String email) {
        this(null, givenName, familyName, email);
    }
    
    Person another = new Person("Sir", "John", "Doe");
    

    In that case, title was the optional parameter, not email. My bad.

    Solving the problem the OOP way

    Object-Oriented Programming and its advocates have a strong aversion to stringly-typed code for good reasons. Since everything in the world has a specific type, so must it be in the system.

    Let’s rewrite the previous code à la OOP:

    public class Title {
        private final String value;
        public Title(String value) {
        	this.value = value;
        }
    }
    
    public class GivenName {
        private final String value;
        public FirstName(String value) {
        	this.value = value;
        }
    }
    
    public class FamilyName {
        private final String value;
        public LastName(String value) {
        	this.value = value;
        }
    }
    
    public class Email {
        private final String value;
        public Email(String value) {
        	this.value = value;
        }
    }
    
    public class Person {
    
        private final Title title;
        private final GivenName givenName;
        private final FamilyName familyName;
        private final Email email;
      
        public Person(Title title, GivenName givenName, FamilyName familyName, Email email) {
            this.title = title;
            this.givenName = givenName;
            this.familyName = familyName;
            this.email = email;
        }
        ...
    }
    
    
    Person person = new Person(new Title(null), new FirstName("John"), new LastName("Doe"), new Email("[email protected]"));
    

    That way drastically limits the possibility of mistakes. The drawback is a large increase in verbosity - which might lead to other bugs.

    Pattern to the rescue

    A common way to tackle this issue in Java is to use the Builder pattern. Let’s introduce a new builder class and rework the code:

    public class Person {
    
        private String title;
        private String givenName;
        private String familyName;
        private String email;
    
        private Person() {}
    
        private void setTitle(String title) {
            this.title = title;
        }
    
        private void setGivenName(String givenName) {
            this.givenName = givenName;
        }
    
        private void setFamilyName(String familyName) {
            this.familyName = familyName;
        }
    
        private void setEmail(String email) {
            this.email = email;
        }
    
        public static class Builder {
    
            private Person person;
    
            public Builder() {
                person = new Person();
            }
    
            public Builder title(String title) {
                person.setTitle(title);
                return this;
            }
    
            public Builder givenName(String givenName) {
                person.setGivenName(givenName);
                return this;
            }
    
            public Builder familyName(String familyName) {
                person.setFamilyName(familyName);
                return this;
            }
    
            public Builder email(String email) {
                person.setEmail(email);
                return this;
            }
    
            public Person build() {
                return person;
            }
        }
    }
    

    Note that in addition to the new builder class, the constructor of the Person class has been set to private. Using the Java language features, this allows only the Builder to create new Person instances. The same is used for the different setters.

    Using this pattern is quite straightforward:

    Person person = new Builder()
                   .title("Sir")
                   .givenName("John")
                   .familyName("Doe")
                   .email("[email protected]")
                   .build();
    

    The builder patterns shifts the verbosity from the calling part to the design part. Not a bad trade-off.

    Languages to the rescue

    Verbosity is unfortunately the mark of Java. Some other languages (Kotlin, Scala, etc.) would be much more friendly to this approach, not only for class declarations, but also for object creation.

    Let’s port class declarations to Kotlin:

    class Title(val value: String?)
    class GivenName(val value: String)
    class FamilyName(val value: String)
    class Email(val value: String)
    
    class Person(val title: Title, val givenName: GivenName, val familyName: FamilyName, val email: Email)
    

    This is much better, thanks to Kotlin! And now object creation:

    val person = Person(Title(null), GivenName("John"), FamilyName("Doe"), Email("[email protected]"))
    

    For this, verbosity is only marginally decreased compared to Java.

    Named parameters to the rescue

    OOP fanatics may stop reading there, for their way is not the only one to cope with stringly-typed.

    One alternative is about named parameters, and is incidentally also found in Kotlin. Let’s get back to the original stringly-typed code, port it to Kotlin and use named parameters:

    class Person(val title: String?, val givenName: String, val familyName: String, val email: String)
    
    val person = Person(title = null, givenName = "John", familyName = "Doe", email = "[email protected]")
    
    val another = Person(email = "[email protected]", title = "Sir", givenName = "John", familyName = "Doe")
    

    A benefit of named parameters besides coping with stringly-typed code is that they are order-agnostic when invoking the constructor. Plus, they also play nice with default values:

    class Person(val title: String? = null, val givenName: String, val familyName: String, val email: String? = null)
    
    val person = Person(givenName = "John", familyName = "Doe")
    val another = Person(title = "Sir", givenName = "John", familyName = "Doe")
    

    Type aliases to the rescue

    While looking at Kotlin, let’s describe a feature released with 1.1 that might help.

    A type alias is as its name implies a name for an existing type; the type can be a simple type, a collection, a lambda - whatever exists within the type system.

    Let’s create some type aliases in the stringly-typed world:

    typealias Title = String
    typelias GivenName = String
    typealias FamilyName = String
    typealias Email = String
    
    class Person(val title: Title, val givenName: GivenName, val familyName: FamilyName, val email: Email)
    
    val person = Person(null, "John", "Doe", "[email protected]")
    

    The declaration seems more typed. Unfortunately object creation doesn’t bring any betterment.

    Note the main problem of type aliases is that they are just that - aliases: no new type is created so if 2 aliases point to the same type, all 3 are interchangeable with one another.

    Libraries to the rescue

    For the rest of this post, let’s go back to the Java language.

    Twisting the logic a bit, parameters can be validated at runtime instead of compile-time with the help of specific libraries. In particular, the Bean validation library does the job:

    public Person(@Title String title, @GivenName String givenName, @FamilyName String familyName, @Email String email) {
        this.title = title;
        this.givenName = givenName;
        this.familyName = familyName;
        this.email = email;
    }
    

    Admittedly, it’s not the best solution… but it works.

    Tooling to the rescue

    I have already written about tooling and that it’s as important (if not more) as the language itself.

    Tools fill gaps in languages, while being non-intrusive. The downside is that everyone has to use it (or find a tool with the same feature).

    For example, when I started my career, coding guidelines mandated developers to order methods by alphabetical order in the class file. Nowadays, that would be senseless, as every IDE worth its salt can display the methods of a class in order.

    Likewise, named parameters can be a feature of the IDE, for languages that lack it. In particular, latest versions of IntelliJ IDEA emulates named parameters for the Java language for types that are deemed to generic. The following shows the Person class inside the IDE:

    Conclusion

    While proper OOP design is the historical way to cope with stringly-typed code, it also makes it quite verbose and unwieldy in Java. This post describes alternatives, with their specific pros and cons. Each needs to be evaluated in the context of one’s own specific context to decide which one is the best fit.

  • Top Eclipse plugins I wouldn't go without

    Using an IDE to develop today is necessary but any IDE worth his salt can be enhanced with additional features. NetBeans, IntelliJ IDEA and Eclipse have this kind of mechanism. In this article, I will mention the plugins I couldn’t develop without in Eclipse and for each one advocate for it.

    m2eclipse

    Maven is my build tool of choice since about 2 years. It adds some very nice features comparing to Ant, mainly the dependencies management, inheritance and variable filtering. Configuring the POM is kind of hard once you’ve reached a fairly high number of lines. The Sonatype m2eclipse plugin (formerly hosted by Codehaus) gives you a tabs-oriented view of every aspect of the POM:

    • An Overview tab neatly grouped into : Artifact, Parent, Properties, Modules, Project, Organization, SCM, Issue Management and Continuous Integration,

      m2eclipse Overview tab

    • A Dependencies tab for managing (guess what) dependencies and dependencies management. For each of the former, you can even exclude dependent artifacts. This tab is mostly initialized at the start of the project, since its informations shouldn’t change during the lifecycle,
    • A Repositories tab to deal with repositories, plugin repositories, distribution, site and relocation (an often underused feature that enable you to change an artifact location without breaking builds a.k.a a level of indirection),
    • A Build tab for customizing Maven default folders (a usually very bad idea),
    • A Plugins tab to configure and/or execute Maven plugins. This is one of the most important tab since it’s here you will configure maven-compiler-plugin to use Java 6, or such,
    • A Report tab to manage the ` part,
    • A Profiles tab to cope with profiles,
    • A Team tab to fill out team-oriented data such as developers and contributors information,
    • The most useful and important tab (according to me) graphically displays the dependency tree. Even better, each scope is represented in a different way and you can filter out unwanted scope.

      m2eclipse Dependencies tab

    • Last but not least, the last tab enables you to directly edit the underlying XML.

    Moreover, m2eclipse adds a new Maven build Run configuration that is equivalent for the command line:

    m2eclipse Run Configuration

    With this, you can easily configure the -X option (Debug Output) or the -Dmaven.test.skip option (Skip Tests).

    More importantly, you can set up the plugin to resolve dependencies from within the workspace during Eclipse builds; that is, instead of using your repository classpath, Eclipse will use the project’s classpath (provided it is in the desired version). It prevents the need to build an artifact each time it is modified because another won’t compile after the change. It merely duplicates the legacy Eclipse dependency management.

    I advise not to use the Resolve Workspace artifacts in the previous Run configuration because it will use this default behaviour. In Maven build, I want to distance myself from the IDE, using only the tool’s features.

    TestNG plugin

    For those not knowing TestNG, it is very similar to JUnit4. It was the first to bring Java 5 annotations (even before JUnit) so I adopted the tool. Now as to why I keep it even though JUnit4 uses annotations: it has one important feature JUnit has not. You can make a test method dependent on another, so as to develop test scenarios. I know this is not pure unit testing anymore; still I like using some scenarios in my testing packages in order to test build breaks as early as possible.

    FYI, Maven knows about TestNG and runs TestNG tests as readily as JUnit ones.

    The TestNG plugin for Eclipse does as the integrated JUnit plugin does, whether regarding configuration or run or even test results.

    TestNG Plugin Run configuration

    Emma

    When developing, and if one uses tests, one should know about one’s test coverage over code. I used to use Cobertura Maven plugin: I configured in the POM and, every once in a while, I ran a simple mvn cobertura:cobertura. Unfortunately, it is not very convenient to do so. I searched for an Eclipse plugin to have the same feature; alas, there’s none.  However, I found the EclEmma Eclipse plugin that brings the same functionality. It uses Emma (an OpenSource code coverage tool) under the hood and, though I searched thoroughly, Emma has no Maven 2 plugin. Since I value equally IDE code coverage during development and Maven code coverage during nightly builds (on a Continuous Integration infrastrcuture), so you’re basically stuck with 2 different products. So?

    EclEmma line highlighting

    ElcEmma provides a 4th run button (in addition to Run, Debug and External Tools) that launches the desired run configuration (JUnit, TestNG or what have you) in enhanced mode, the latter providing the code coverage feature. In the above screenshot, you can see line 20 was not run during the test.

    Even better, the plugin provides a aggregation view for code coverage percentage. This view can be decomposed on the project, source path, package and class levels.

    EclEmma statistics

    Spring IDE

    Spring does not need to be introduced. Whether it will be outed by JEE 5 dependency injection annotations remains to be seen. Plenty of projects still use Spring and that’s a fact. Still, XML configuration is very ankward in Spring in a number of cases:

    • referencing a qualified class name. It is not neither easy nor productive to type it; the same is true for properties
    • understanding complex or big configurations files
    • referencing a Spring bean in a hundred or more lines of file
    • refactoring a class name or a property name without breaking the configurations files
    • being informed of whether a class is a Spring bean in a project and if so, where it is used

    Luckily, Spring IDE provides features that make such tasks easy as a breeze:

    • auto-completion on XML configuration files
    • graphic view of such files

      Spring IDE Graph View

    • an internal index so that refactoring is takes into account the XML files (though I suspect there is some bugs hidden somewhere for I regularly have errors)
    • a enhanced Project Explorer view to display where a bean is used

      Spring Project Explorer View

    This entire package guarantees a much better productivity when using XML configuration in Spring than plain old XML editor. Of course, you can still use Annotation configuration, though I’m reluctant to do so (more in a latter post).

    I conclusion, these 4 integration plugins mean I feel really more comfortable using their underlying tools. If I were in an environment where I couldn’t update my Eclipse however I choose, I would definitely think about using these tools at all (except Maven), or use Annotations configuration for Spring. You can have exceptional products or frameworks, they have to integrate seamlessly into your IDE(s) to really add value: think about the fate of EJB v2!