DEV Community: Simon Taddiken

What do you think about Mozilla Firefox weakening TLS security?

Simon Taddiken — Tue, 02 Jul 2019 18:26:08 +0000

Mozilla Firefox is about to add an option (which is enabled by default!) that will make it easier for anti virus software to act as man in the middlle in order to decrypt and analyze encrypted HTTPS connections.

More information can be found in the mozilla knowledgebase.

I think this fundamentally subverts the whole purpose of TLS and trusted CAs. It is sad that browser manufacturers have to add security loopholes in order to gain acceptance of clueless users who expect higher security through running useless anti virus software.

Maybe there is a security expert around who can reasonable justify and explain this step?

Duck typing in java

Simon Taddiken — Tue, 09 Apr 2019 20:12:04 +0000

Disclaimer: please don't take this too serious. It's just fun and games.

Duck typing is an idiom known mostly from dynamically typed languages. It states that you can treat unrelated Objects of type X as Objects of type Y as long as both have the same public interface.

If it looks like duck, moves like duck and makes sounds like a duck then it must be a duck!

Java's static type system on the other hand, imposes strong rules on type compatibility. Just having the same methods doesn't qualify two classes to be "type compatible". Consider this example:

public class Duck {
    public String makeNoise() {
        return "Quak Quak";
    }
}

public class Dog {
    public String makeNoise() {
        return "woof woof";
    }
}

Both classes have the same interface, so can we assign instances to the respective other type?

final Duck duck = new Dog(); // fails
assertEquals("woof woof", duck.makeNoise());

Of course we can't. Java's type system needs explicit definitions of compatible classes using inheritance.

Let's now make our example work using the easiest imaginable change to our code:

public class Dog extends Duck {
    @Override
    public String makeNoise() {
        return "woof woof";
    }
}

Besides everything you learned in biology classes our Dog now is a duck and is thereby assignable to variables with type Duck. This change should have made the test above turn green.

Ok, now our Dog is a Duck, but what about all the other classes in our code base that also have a makeNoise method? Should they all extend the Duck class? That seems impractical and confusing (class Train extends Duck is even stranger than a Dog being a Duck).

Maybe we can build a more dynamic Duck by using reflection. During runtime the JVM has pretty extensive type information about every object. Besides accessing type information, reflection also allows us to dynamically retrieve and call methods on arbitrary objects.

public class DynamicDuck extends Duck {

    private final Object notADuck;

    public DynamicDuck(Object notADuck) {
        this.notADuck = notADuck;
    }

    @Override
    public String makeNoise() {
        // try block is needed because the reflection stuff will 
        // throw all kind of horrible exceptions if you use it wrong
        try {
            // retrieve dynamic type information of the non-duck object
            final Class<?> notADuckType = this.notADuck.getClass();

            // find the method of the class that is not a duck by name
            final Method delegate = notADuckType.getMethod("makeNoise");

            // invoke the method on the object that is not a duck
            return (String) delegate.invoke(this.notADuck);
        } catch (Exception e) {
            throw new IllegalStateException("DynamicDuck error");
        }
    }
}

Using our DynamicDuck we can get a "duck-view" on every non-duck Object. Let's adjust our initial test accordingly (and also remove the extends clause in the Dog class):

final Duck duck = new DynamicDuck(new Dog());
assertEquals("woof woof", duck.makeNoise());

That's a little more dynamic but still doesn't scale well. If the Duck class had more public methods we'd have to delegate every method to the non-duck Object like we did above. And if we decided not to view everything as a Duck, but as a Goose, we need to additionally create a DynamicGoose class. That's all way too cumbersome.

Luckily, Java has another useful concept that comes in handy for our use case. Every class that is available during runtime will be loaded from its byte code representation using a ClassLoader. As this is a pure runtime feature you can make up artificial classes during runtime that did not exist during compile time.

We can dynamically generate the byte code of a class that extends Duck and which automatically delegates every called method to the equivalent method of an arbitrary non-duck Object. The following code uses the popular libraries cglib (for byte code generation) and Objenesis (for instantiating the dynamically generated classes.

import net.sf.cglib.core.DefaultNamingPolicy;
import net.sf.cglib.proxy.CallbackFilter;
import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.Factory;
import net.sf.cglib.proxy.InvocationHandler;
import org.objenesis.Objenesis;
import org.objenesis.ObjenesisStd;

import java.lang.reflect.Method;

public class NotADuck {
    /**
     * The unique callback index to which each method in the proxy object is mapped.
     */
    private static final int CALLBACK_INDEX = 0;

    /**
     * Maps all methods to index {@link #CALLBACK_INDEX}.
     */
    private static final CallbackFilter ZERO_CALLBACK_FILTER = method -> CALLBACK_INDEX;

    // with caching
    private static final Objenesis OBJENESIS = new ObjenesisStd(true);

    public static <T> T asDuck(Object notADuck, Class<T> type) {
        final Enhancer enhancer = new Enhancer();
        final InvocationHandler invocationHandler = new DelegateDuckToNonDuckMethod(notADuck);

        enhancer.setSuperclass(type);
        enhancer.setUseFactory(true);
        enhancer.setNamingPolicy(new DefaultNamingPolicy());
        enhancer.setCallbackFilter(ZERO_CALLBACK_FILTER);
        enhancer.setCallbackType(invocationHandler.getClass());

        final Class<T> proxyClass = enhancer.createClass();
        final T duckInstance = OBJENESIS.getInstantiatorOf(proxyClass).newInstance();
        final Factory factory = (Factory) duckInstance;
        factory.setCallback(CALLBACK_INDEX, invocationHandler);
        return duckInstance;
    }

    private static class DelegateDuckToNonDuckMethod implements InvocationHandler {

        private final Object notADuck;

        private DelegateDuckToNonDuckMethod(Object notADuck) {
            this.notADuck = notADuck;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            final Method nonDuckMethod = notADuck.getClass().getMethod(method.getName(), method.getParameterTypes());
            return nonDuckMethod.invoke(notADuck, args);
        }
    }
}

Using this class, we can create a dynamic, duck-view of a Dog instance:

final Duck duck = NotADuck.asDuck(new Dog(), Duck.class);
assertEquals("woof woof", duck.makeNoise());

The code is no longer restricted to only create Duck objects:

List list = NotADuck.asDuck("I'm a String", List.class);
// both List and String have an isEmpty method
assertFalse(list.isEmpty());

This was just a little experiment. There are likely bugs, uncovered edge cases, performance issues and general lack of practical use cases in this implementation. Nevertheless it's fun to see how far you can go with Java's dynamic type information and materialization of arbitrary byte code.

Don't do this at home!

Should I write a library?

Simon Taddiken — Thu, 21 Mar 2019 09:01:39 +0000

Every mid-sized project likely has experienced a point in time where its members were to decide whether or wether not to outsource common code into its own library artifact. The main reason for this is mostly to save on duplicated code and to DRY (don't repeat yourself). Sadly, I have seen this to backfire so dramatically in some projects, that duplicated code might have been the better solution. That is because:

DRY has one major tradeoff: it introduces dependencies.

Say you have identical code parts in Service A and B. These parts are completely independent. In case the requirements for the implementation in Service A changes, Service B can remain untouched. That is a pretty comfortable situation because it gives you great freedom in applying changes.

If you had moved the common code into its own library artifact and the requirements for service A are changing

you update the library code and release it as new version
you update the library dependency in Service A

In my experience, what happens next is either of the following:

you forget to update the library dependency in Service B
you update the library dependency in Service B to find out that your changes broke the implementation in B
you update the library dependency in Service B to find out your latest changes work just fine in B. Unfortunately you broke an unrelated part, because the latest version of your library also contains earlier changes for which you forgot to update the dependency
you update the library dependency in B and everything works as expected (yeah, sure)

These problems obviously get worse with every further Service that uses your library. You now need to update every client of your library, although you needed a change only affecting a single client. Or you choose to not actively update the dependencies in other services and perform a large migration later on (or never).

Before carelessly extracting common code, apply some thoughts to the following topics.

Selecting the scope

Before deciding to move common code into a library, you have to understand why you have the same code in different locations to begin with. It might be pure coincidence because of similar (but actually unrelated) business requirements in Service A and B. Business requirements are likely to change in a unforseen and incompatible way. So it is probably not the best idea trying to unify your business logic into a library.

On the other hand, if you have code that serves purely technical purposes like managing database connections, logging, serving REST endpoints and the alike, it can be really worthwhile considdering to refactor these stuff into a reusable library. If such a technical aspect changes, it is likely that these changes are beneficial for other users of this code as well.

When deciding to use a shared artifact for commonly used code, do not make the mistake of mixing different concerns into this artifact. Don't put your database connection management together with your logging code. There should only ever be a single reason of why you would apply a change to your library. This also mitigates bullet 3. from above as we are reducing the probability of breaking unrelated parts.

Don't start your project with writing a library that might later be used by multiple clients. You don't know the actual requirements yet and are darned to emphasize on the wrong parts. Simply put:

// Detect dark theme var iframe = document.getElementById('tweet-988571579536826368-818'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=988571579536826368&theme=dark" }

Managing change

If you extracted parts of your code base into a library, you have to plan for upcoming changes and how you want to handle them.

Design your library code to be extensible from the "outside"
Have a migration strategy in case you need to change the library
Have a deprecation strategy to be able to remove code from the library in the long term
Have a notification strategy to announce new releases

Designing for extensibility can be exhausting. You have to think about valid extension points and need to predict future requirements. There might always be some obvious interfaces that can easily be made customizable, but there will be the interfaces you didn't know you need until the actual requirement comes up. Chances are high that you invest a lot of time in planning ahead and to over engineer your code in order to be prepared for every possible change to come. Or, you don't, and end up applying changes and releasing new library versions every other day.

You have given up the freedom of freely applying changes to every part of your code base. Now, whenever you have to change even the smallest part in your library, you have to keep in mind that you might break code that depends on this part. According to Hyrums Law you not only might break, but you actually will break code if there are enough users of your library:

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

Without a deprecation strategy you end up carrying around old code for ages. If you have no way of informing clients for classes and methods that are no longer to be used, you will either end up maintaining this code for the lifetime of this library or you remove it without announcing and hit your clients unprepared when they migrate to the next version.

It now starts to feel more like building a product than doing the simple refactoring of moving code around. The more users your library has the more weight has to be put on those single topics. On the other hand, the less users your library has, the less is the effect of saved efforts. It is a constant tradeoff between maintaining duplicated code and maintaining changes to the library.

Summary

The overhead of managing a library can be intimidating, especially if you need to do it in parallel to an actual project. On the other hand, if your overall goal is to write, ship and maintain a library, these topics give you a good start at what to take care of.

I tried to emphasize the tradeoffs you have to consider when introducing shared code to your project.

So, Should you write a library?

As often in software development, there is no binary yes or no (which is kind of ironic, isn't it?) but only the good ol' it depends.

The beginner's guide to Spring Boot

Simon Taddiken — Wed, 13 Mar 2019 16:39:45 +0000

Disclaimer: This article probably seems shorter than you have expected regarding its title. In the end you will have learned that it's not.

Spring Boot is the one big player in the market of available java application frameworks. Everybody is supposed to know Spring Boot and how to write applications using it. Yet, you see so many Spring Boot applications that have gotten out of control and are a nightmare to maintain. Why is that?

In my opinion, this is because it is so easy to get started - you put an annotation here, you put an annotation there and voilà you have your REST service running. But then, it is not quite as easy to evolve and structure your application correctly if you are not aware of some key concepts and some of the stuff that is going on under the hoods. Without proper understanding, it is way too easy to screw things up. Examples?

Application context configuration seems easy at a first glance but can get rather complex while your application grows. Do I use component scan or java based configuration? Can I mix them? Where do I put those config classes? Is a single @Configuration class enough? What is this 'auto configuration' actually? If you can not properly answer these questions in context of your application's requirements you will end up creating an unmaintainable ApplicationContext hell.

There are other examples like scopes, logging configuration, property sources, AOP proxies, dependency management, bundling, profiles, web security and whatnotelse.

In short: If you thought that writing an application using Spring Boot is as easy as putting @SpringBootApplication on your main class, you are wrong. It is just as easy to screw everything up if you have no idea what you are actually doing.

So here is my advice if you want to get serious with writing a Spring Boot application: RTFM

(Really, that is the single most important resource to learn how Spring Boot works)

How a great package structure can make a great application

Simon Taddiken — Wed, 10 Oct 2018 07:38:46 +0000

In this post I will give you some simple advice that, when followed carefully, will immediately lead to an easy to maintain and scalable architecture of your Java application. While this post is dedicated to Java the concepts will equally apply to other languages that allow to arrange code in packages.

One could write books of how to achieve good architecture (and people did) but you need a better architecture right now and are short of time - and so am I - so let's jump into it. Everything I'm going to tell you now boils down to this single most important advice:

Use package private scope liberally

If you do, this solves so many problems at once that, once you got used to it, you will hopefully be as amazed as I was when I realized how valuable this advice is. Let me explain this in detail.

In bigger applications the key to maintainability is to keep coupling of the
application's single components under control. This assumes that your application must actually be structured into components in the first place. If it is not, you probably alreay experienced some kind of inter-package-dependency-hell with package cycles and the alike (the good ol' big ball of mud).

Dependency is the key problem in software development at all scales (Kent Beck)

Java provides the concept of packages to structure your code into components. But experience taught me that most times, a single component is spread across multiple packages. This happens when programmers choose their packages under technical aspects. For example if you have a package org.domain.app.controllers where all your controllers live and another package org.domain.app.services where all your services live you have a technical package structure. In this scenario, possibly unrelated classes are located near to each other in the same package while related classes are located far away.

Locality of related code is a key aspect of having code that is easy to reason about

Because your related classes, which together solve a certain domain specific problem are located in different packages, they all have to be public in order to work together. By choosing to not place related classes into the same package you open yourself up to all the evil of having certain classes used in places where you don't want them to be used.

If upfront you chose a domain or feature related package structure there were an easy soultion to avoid this problem in the first place:

Give as many as possible classes the package private scope

Actually you should, by default, make every class package private and only broaden its scope if necessary. After some time you will develop a bad feeling whenever you see something beeing public - and this is a good thing. It makes you think explicitly about the public interface of your package. Following this advice you will automatically create packages with following characteristics:

high cohesion: everything in the package is kind of related to the other things. The locality of related code will make it easy to reason about.
low coupling to other packages: because there is only a minimal public interface of your package

While these are good things you will also experience that your packages grow bigger and bigger up to a size that make you feel uncomfortable.

If you feel your package is growing too big that is a clear sign that there might be a better domain specific cut. In this situation you should review and question the whole purpose of the current package. In my experience you run into the following cases:

Your original feature got undermined by unrelated code which actually serves a different feature.
As time passed, the requirements for the original feature changed that much that the original structure does not fit sufficiently anymore. It might also well be possible that the feature did not change, but your understanding of it did while you were coding it.

Most times the first case is simple to solve. If you are really in a situation where mostly unrelated code slipped into your feature package it should be pretty easy to isolate it and move it into its own package.

If isolating smaller parts is not that easy you might be subject to the second case. This is where the sorcery of package private reached its limits and you will have to do actual work. You are now up to some refactoring on package level - that is you need to split your current package into multiple new ones which better suit the requirements of the domain problems you are trying to solve. This is most likely not solvable by only moving some classes between packages but might require actual code changes.

But because everything related is so near together and you know that most things are not used outside the package this gives you great confidence while refactoring.

Have you ever wondered what the unit in unit testing is? You might have come across test suites where a test class exists for every production class. If so you most likely experienced that your unit tests are not very robust. They break easily if you adjust the implementation class even if you actually preserved behavior correctly. That is because unit does not mean class. Unit pertains to all the code you want to test in isolation in order to solve a domain specific problem. Unit means feature and feature, in our case, means the public interface of your package.

Don't write a test class for every production class. Write a test class for every feature

Doing so loosely couples your test code to the production code in the same way your production code is loosely coupled to other packages. You can freely change all the implementation details (like, even delete classes) behind the public interface without breaking your tests. That is the very meaning of information hiding.

To summarize, by using package private scope liberally you get (for free!)

high cohesion within your packages
low coupling between packages
a durable architecture because of well defined interfaces between components/packages
code that is easier to reason about
a good hint of what you should test in order to achieve more robust unit tests

And again: you get this for simply leaving out the public modifier in you class declarations! Whenever you feel the need to create a new class, make it package private and place it into the package where, from a domain or feature point of view, you think it fits best. This puts you in a position where you can evolve your package layout carefully over time.

Addendum
The attentive reader might have noticed the following: the above tips on structuring your packages is actually the same advice we followed along for decades on class level. It is undisputed that it is best practice to keep helper methods private in order to have a well defined public interface. If "dependency is a problem at all scales" it is likely and expectable that the solutions for managing dependency look similar at all scales too.

More information:

Simon Brown on 'package by component': http://www.codingthearchitecture.com/2015/03/08/package_by_component_and_architecturally_aligned_testing.html
https://github.com/olivergierke/moduliths (A spring Boot extension which tries to enforce this way of structring your application)
Somthing about to DDD