In this blog, I would like to share something I recently discovered when studying for the Java 11 certification. Strangely enough, it is not a new Java 11 feature. It’s not even something introduced in Java 8 or 7. No, it’s something that's been around since the early days of version 6. It’s the ServiceLoader class. A long-forgotten feature which thanks to the introduction of modules in Java 11 has become especially relevant again.

The ServiceLoader class was first introduced in Java 6. It was used to make applications extensible, so you could add functionality without recompiling the whole application. Basically, the SeviceLoader scans the classpath looking for an implementation of any interface you may want and returns the results, which then can be used at runtime in your code. Essentially, this is a form of dependency injection.

Dependency Injection
What is dependency injection and why is it important? Quality code should adhere to the following design principle:

This principle is not rocket science. It simply means that an object that uses another object should not create that object, but instead receive the objects it is dependent on. This technique is called dependency injection.   

There are many ways of injecting dependencies into objects. 

1 - You could use a framework. There are quite a few dependency injection frameworks Java developers can choose from. For example, Spring Framework or Google Guice are very popular. 

2 - However, a framework is not necessary. There are far simpler techniques for achieving the same goal. There are several methods of dependency injection in Java without the need of leveraging third party frameworks and only rely on simple regular everyday code. The simplest are: 

Constructor injection. The dependencies are injected via constructor parameters. 

Setter injection. After the object has been initialized, setter-methods are used to add the dependency. 

Factory method. Similar to the Constructor injection method, however, the constructor is called with the necessary parameters within a method belonging to a Factory class.  

Factory injection. This is an improvement to the Factory method. By implementing the Factory Pattern. Basically, all the logic needed to initialize the object with all the necessary dependencies are abstracted away within an independent class, a Factory class. This object internally decides which dependencies are needed. 

The main advantages of these methods are that you don’t need to add any external libraries to your build path, nor do you need to use any ‘funny looking’ annotations to tell the framework what needs to be injected and where. It is done in plain old, easy to understand Java code.  

3 - “But I need to dynamically switch between implementations in my code”, I hear you say. Yes, there are some use cases where you may need to load an implementation of a class at runtime. Luckily, that’s not a problem in Java. There is the ServiceLoader class. 

As previously discussed, this class has been around since version 6, and can be found in the java.util package. This class will scan through the classpath or (from version 11) through the module path of your application and retrieve the available implementations. Giving you a Java native way of dynamically loading classes and injecting them into objects. Most probably in conjunction with some kind of Factory class to abstract away some of the code.

Module path
Before we dive further into the workings of the ServiceLoader class, I need to discuss the new module system introduced in Java 11. 

In layman terms, in Java 11 the classpath has been replaced by a module path. Don’t panic, you can still use a classpath, but this is no longer advised. 

The biggest difference between a classpath and the newer module path is that when using a classpath Java searches through all the locations designated on the classpath looking for the class to use. Often, this works fine. However, it is possible to have multiple instances of the same class defined on your path. And because Java has no strict way of traversing through the classpath, your application will randomly use different implementations of a class. Potentially causing all kinds of unpredictable problems, colloquially called “Dependency Hell”.

This has been fixed in the module path way of working. Instead of an unorganized collection of available classes. Classes and packages are now ordered into neatly organized modules. And because modules need to declare which classes they make accessible for other modules and which modules they use; java has the ability to validate all modules loaded at compile time helping to prevent dependency hell. 

The ‘exports’ keyword is used for making packages available and the keyword ‘requires’ is used for declaring which modules are used. This information is placed in the module-info.java file, which can be found in the source folder.

ServiceLoader
As previously described, the ServiceLoader is able to search the classpath looking for implementations. But how does it work when using a module path? Modules no longer implicitly expose any classes. Therefore, an implementation (also called a Service in Java 11) needs to be exposed to the outside world. This is done by using the keywords ‘provides … with ...’. Also, you need to declare that a module uses an external implementation. This is done by using the ‘uses’ keyword.

Module 1 – The module exposing (exporting) the interface
Module definition

Module 2 – The module providing the service implementation (doesn't need to be exported!)
Module definition

 Module 3 – The module using the service: 
The module definition of a module using a service.

If all the modules have been correctly defined, then using the ServiceLoader is easy. You only really need to know one static method ‘load’ which takes a class as a parameter and returns a collection of Classes. Because the ServiceLoader can retrieve an unknown number of classes, you will have to write some code to determine which class instance (if any) to use.

Summary
To quickly summarize. In many cases of injecting dependencies, we don’t need a framework to get the job done. Java out-of-the-box offers us the tools needed to solve the problem of dependency injection.

In this blog, I would like to share a long-forgotten feature which has become especially relevant again, the ServiceLoader class

The ServiceLoader and Native Dependency Injection in Java 11

In this blog I want to give a short introduction into the use of monads in Java. Interestingly, the concept of a monad has been around for quite some time now. Originating in mathematics it’s a design pattern which has previously only been popular in functional programming languages. However, it has found its way to Java. There is even a large chance that you have already been using them unknowingly. Especially, if you have been using the Optional and Stream libraries introduced in Java 8. So, what is a monad and how does it help me write clearer code? 

The Problem
First, I’m going to start with the problem that a monad helps us to solve. Its main goal is to help abstract away boiler plate code that isn’t the main concern of your code. Think of null checking, exception handling, validation, logging, concurrency, etc. 

In this first code block, four classes have been declared. The first three classes represent a bank with customers which in turn may each have an active account. The Bank class has a single method which returns the Customer with the supplied id. The Customer class has a single method which returns the customer’s Account. The Account class also has a single method which returns the balance of the account. The final class ATM has a single method which takes a Bank instance and an id as a parameter and returns an account's balance.

The problem is that the methods in Bank, Customer and Account may return null. The id might not be correct, or the customer may no longer have an account at the bank, or the balance may not be available. This will result in the fetchBalance method of the ATM class throwing a NullPointerException, which will cause the program to crash.

We can fix this by refactoring the fetchBalance method to check if each value returned by Bank, Customer or Account happens to be a nullpointer (Alternative 1). We can all agree that this code works, but it’s not a pleasure to read. Alternatively, you could use nested if-statements to check for not null. However, this also has little effect on the readability of your code (Alternative 2).

 Another alternative (Alternative 3) would be to place the code in a ‘try-catch’. This would improve the readability, but hide the cause of the exception, limiting your ability to later add some code to be able to recover from the exception. 

What is a Monad?
 So, what is a monad and how can it help us write more readable code? A monad is defined as any class (data type), which represents a specific calculation. It must implement at least these two functions:

A function to wrap any basic value, creating a new monad. Also called the return function.

And a function that allows you to perform operations on a wrapped data type (monad). Also called the bind function.

It must also adhere to the following three monad laws:

Left identity, passing an operation to a monad should yield the same result as applying the operation to the original value.

Right identity, passing a wrapper function to a monad should yield the same result as creating a new nomad.

Associativity, when chaining functions, it should not matter how the functions are nested.

The first two identity laws basically say that the only thing the return function is allowed to do is to wrap the object. It cannot manipulate the data in any way.

The final law ensures that it doesn't matter how bind functions are nested, the results are the same. Which simply means that the same sequence of operations will always produce the same value.

In Java the Optional class has all the necessary characteristics of a monad:

Does it represent a specific calculation? Yes, it encapsulated a mechanism for performing actions on values safely without causing a null pointer exception. 

Is there a function for wrapping basic values and creating a new monad? Yes, ofNullable which takes any value and returns a new Optional instance containing that value. 

Does it have a function to allow operations to be performed on its contained value? Yes, flatMap does the trick nicely. 

Does it adhere to the three monad laws? The short answer is yes.

Other commonly used monads found in Java include: Stream<T> (and all the different types of streams) and CompletableFuture<T>.

How do monads solve our problem?
Now that we know what a monad is, let’s use the Optional monad, also known as the Maybe monad in other languages, to clear up our code.


Refactored code using the Optional monad.

We start by changing the return type of the getter methods in the Bank, Customer and Account classes, we do this by using the ofNullable method to wrap the return values. Thanks to the Optional we have also clearly declared that the methods may return null. 

Then, we refactor the ATM's fetchBalance method. First, we wrap the Bank input parameter in the Optional monad. Finally, we use a chain of flatMap calls to perform operations on the wrapped value. Each time calling a getter method to replace the value inside the Optional with a new value. If at any time the value becomes null, any remaining transformations have no effect.

After refactoring, we end up with code that is easier to read and safer to run. The messy null pointer checks have been abstracted away and you are left with a chain of declarative transformations. Not bad.

 And now?
I hope you enjoyed reading this introduction to monads in Java. Now that you have a general idea what a monad is, you should have an easier time following other more in-depth articles, blogs or presentations about this subject.

In this blog I want to give a short introduction into the use of monads in Java.

Monads in Java: a short introduction

Don’t worry! I’m not going to talk about dressing up casually for work as the title may suggest. This is going to be a little story on how, after eight years since introduction, I stumbled into using functional style programming. Apart from using the occasional Java Stream here and there, I never wrote any code in a functional style kind of way. Until now that is…

An important aspect of my current project is logging. One of the requirements we defined for testing is that we want to be able to assert that things are logged correct. The objective was simple. Write a piece of code that can do that in an easy way (and if the code is flexible then that is a plus).

As a huge clean-code fanatic, instead of starting to type relentlessly and crank out the code as I go, I started at the end. How do I want it to look when I use my custom made class? How can I design it in an elegant way?

Asking myself these kinds of questions made me sort of design the code upfront. Which sounds to me like doing the right thing. And while I am at it I might as well throw in some TDD and write a test for my custom LoggerSpy first.

Awesome! Short, concise and it does the job. Although it is clear what LoggerSpy does, it isn’t very flexible. It accepts a string and checks if the list of log events contains a message that exactly matches the given string.

But what if I want to check if the log contains a message that ‘starts’ with a given string? Or ‘ends’ with it? Or complies to a certain regex? Should I make extra public methods in my LoggerSpy for each of those checks? That doesn’t sound overwhelmingly flexible.

My next design attempt was something along the lines of the Hamcrest library. It’s time to introduce the ‘equalTo’ matcher.

Now I could potentially make a matcher for every way I want to match my  log message against a given string. The code reads well, it is flexible, the call to containsMessage is very self-explanatory and it looks nice also. This seems like a good time to start implementing the whole thing.

My first reflex for implementing LoggerSpy was doing it hardcore Java style. None of that functional style voodoo code! (Note: by voodoo code I mean code that seems to work great but you don’t quite understand what it does or how it exactly works) 

Job accomplished. My design is implemented. The usage of the LoggerSpy is clean and simple. But we already knew that since we designed it upfront. The only thing that bugged me was the amount of boilerplate code needed.

1. for each type of matcher (equaITo, startsWith etc.) I had to create a separate class, create a static method that accepts a String value and create a field to store the String value. While actually the only thing that truly matters is this piece of code: 




2. and since I have to create a different class for each type of matcher, I had to create an Interface (LoggerSpyMatcher) as well in order to pass along all my different types of matchers to the containsMessage method.

But altogether a very good attempt. The main goal was easy and flexible in use. Commit-Push. Next story…

A week or so later I accidentally stumbled upon a talk by a software engineer called Mama Samba Braima (aka Nelson). In that talk he explained functional style programming in an easy to follow manner. What first seemed like reading a book written in Chinese started to make some sort of sense to me all of a sudden.

What if I saw functional style programming as a way to create methods that you can pass along to another method and execute it inside that other method when needed? Although this explanation feels like selling the concept of functional style programming a bit short and not telling the whole story, it was a good metaphor that helped me visualize it a bit better. All of a sudden the idea of refactoring my LoggerSpy functional style was born.

If you take a look at the java.util.function package you’ll see all these kinds of interfaces. Consumer, ObjLongConsumer, Supplier, DoubleSupplier, Function, BiFunction, Predicates. There are 43(!) of those guys in there. Not very inviting to read.  

But as it turns out these functional interfaces are basically descriptions of the kind of method that you want to pass. It defines the input parameter(s) and the return type, for instance:

a Function<String, Integer> represents a method that you want to pass which accepts a String as input and returns an Integer as output.

a BiFunction<String, Long, Integer> represents a method that you want to pass which accepts a String and a Long as input and returns an Integer as output.

a Consumer<String> represents a method that accepts a String and returns nothing.

a Supplier<Integer> is the opposite of a Consumer, it accepts nothing but returns an Integer

a Runnable doesn’t accept anything and it also returns nothing. It’s like Nike. It just does something. 

a Predicate<Person> represents a method that accepts a Person object as input and returns a boolean.

There are many more functional interfaces but it is basically all the same.

I read about Functions… and then it clicked…

As you can see in the code example above, my “matches” methods in the non-functional style LoggerSpy  accept a list of ILoggingEvents and return a boolean.

So, for my functional style LoggerSpy to work I need to create matchers of type Predicate<List<ILoggingEvents>>.

That piece of code above looks confusing at first glance. EqualTo returns a LoggerSpyMatcher while events.stream().anyMatch() would return a boolean, huh??? But it is not the value (or the outcome) of the anyMatch method that the equalTo method returns. Nope, it is the “logic” itself that the equalTo method returns.

Looking good, but all I have created up until now are my “methods” that I want to pass to the containsMessage method of the LoggerSpy. I can pass along all the matchers that I want but at this point it doesn’t do anything.


The only thing that I need now is a way to invoke the matcher. That is where the “Single Abstract Method” (SAM for short) of a functional interface comes into play. 

All I have to do now is call the SAM on my matcher object inside my containsMessage method. Calling that method on my matcher invokes the method that I just passed into my containsMessage method and returns a boolean result.

… and I use LoggerSpy in my tests like this

Super clean, simple and easy to use. Never thought that I would end up actually using functional style programming after all this time. But I have to admit… I kinda like it!

The full working example can be found on my GitHub:

https://github.com/vlouisa/logger-spy/tree/feature/functional-style

https://github.com/vlouisa/logger-spy/tree/feature/non-functional-style

Functional style programming - a story of a software engineer who tries it for the first time.

Functional style programming in Java

Oh no! I am going functional style after all this time...

In april 2021, Bouke Nijhuis has discussed 4 tips for passing the Java 11 Developer exam. In this blog I am going to expand on those original tips and add some more. 

The Java Developer exams are notorious for asking difficult and misleading questions. But why do so many people find them so hard? Do they just lack experience? Are the questions incredibly difficult? Don’t you have enough time to answer all the questions? The simple answer to all these questions is ‘No’. Not that it’s an easy exam, but with the right preparation you can pass it during your first try.

I have previously taken the various Java 7 and 8 OCA/OCP exams before starting to prepare for this exam. And let’s be honest the difference between Java 8 and 11 compared to the difference between Java 7 and 8 is minimal. Beside adding a few new methods here and there, and adding annotations to the scope of the exam. I can only say that the new feature of modules is the only significant change from 8 to 11. However, I scored lower during this exam than the Java 8 OCP I took 3 years ago. Have I become a worse developer over time? What’s wrong?

Well no. Practice makes perfect, but only the right practice. This introduces my first tip.

Ironically, the more experience you have as a developer after a point the test will become harder, not easier. Why? Simple, because the majority of the stuff tested during this exam you never really need to memorize by heart when working as a developer. 

For example, we all know auto type conversion in Java: an int can safely be converted to a float, and a float in turn can be safely converted to a double. But what about a short to a char. Or a char to an int? Or a boolean to a byte. The exam won’t directly ask you this. But when looking for compile errors there could be a few questions where answers differ only by type. When taking the exam, I found myself hesitating and wasting a lot of time on such simple things. 

It is also important to note that Oracle has decided to no longer split the exam into two parts: the OCA and the OCP. Now it is just a single larger exam. The OCA consisted of the more basic fundamentals and the OCP covered the ‘more difficult’ concepts of lambda's, extended libraries, modules, etc. So, I thought that it would maximize my chances of passing if I focused 95% of my time on the (formally) OCP chapters of the study book and just quickly scan the other ‘easier’ chapters. I was wrong. I would estimate that 60% - 70% of the questions were straight out of the Java 8 OCA exam. 

In short, it is easy to pass by having a good knowledge of the basics and an ok knowledge of the more advanced topics.

Tip 6 - Practice as many exam questions as possible

Remember you are not only studying to be a good Java developer; you are also studying to be a good test taker. In an ideal world, these would be the same thing. However, that is not the case. It is important that you learn how to read and answer the Oracle exam questions.

The only way to do this is by answering as many practice questions as possible. The questions provided by your study guide of choice, is a great place to start. However, I would also take advantage of the many other sources available. 

For example, the creators of the “OCP Complete Study Guide'' also offer a complementary book containing hundreds of pages of extra practice questions. You can also find online practice exam software which can be purchased and accessed via Udemy or other educational platforms. 

I cannot stress how much I learned while answering practice questions. Not only is this the best way of getting to grips with the material, but the best way to reduce the time you need to answer a question. Making you better and faster at answering the exam questions. 

So, the moment has come and you are sitting behind a computer ready to take the exam. You will need to answer 35 of the 50 questions correctly in 90 minutes to pass. Time is going to start flying. What can you do to maximize your time management?

Fortunately, you can easily flag questions and revisit them later after completing the final question. My tactic is to, first, quickly go through all the questions not spending more than 20/30 seconds on a single one. If the question appears large or it seems like you are going to need more time walking through multiple steps keeping track of the value of a variable, just flag it and move on. If you are hesitant between two answers, flag it and move on. If you read a question and you panic, flag it and move on.

Most likely, the majority of the questions will be relatively straightforward, you should know the answer in at least 30 seconds. At least by answering these questions first, you will have answered the questions you find easy, and after realizing that you are confident that you have answered 50-60% question hopefully correctly, you will be more confident and less stressed to be able to take the time needed to answer the questions you flagged on a second run.

During the second run continue following the first tactic, but now unflag the questions you feel confident are correct. You will be left with less flagged questions. Now just repeat until there are no questions left, or you run out of time. Most of the time I find myself with time to spare, or just staring at one or two questions at the end. No big problem.

A final tip, sometimes the clock runs down to zero and the exam automatically finishes before you have answered every question. Therefore, it is important before going to the next question to always give an answer. If you don’t know, just guess. Nothing ventured, nothing gained. If you flagged the question, you will have another chance and hopefully enough time to give a more confident answer.

A previous blog has discussed 4 tips for passing the Java 11 Developer exam. In this blog Ian van Nieuwkoop is going to expand on those original tips and add some more.

Four more tips to pass the Java SE 11 Developer exam

In de afgelopen jaren heb ik bij verschillende opdrachtgevers in diverse branches mogen werken, zo ook bijvoorbeeld voor de overheid. Vanuit een van deze opdrachtgevers was de wens om een nieuw platform te bouwen en beschikbaar te stellen aan meerdere doelgroepen en moest deze diverse functionaliteiten ondersteunen. De keuze stond vooraf al vast dat deze applicaties en API’s via een microservices architectuur ontwikkeld zouden gaan worden. 

Kort gezegd bestaat een landschap van microservices uit applicaties die ontwikkeld zijn als een verzameling van applicaties (dus functionaliteiten). Elke applicatie kan je zelfstandig ontwikkelen, implementeren en onderhouden zonder afhankelijkheden van andere applicaties.

Om een idee te geven hoe het platform is ontwikkeld doe ik in deze net alsof wij een pizzeria genaamd “De CINQeria” zijn met soortgelijke vraagstukken, namelijk:

De consument wil een lijst van pizza’s zien, samenstellen en bestellen via de website en een app;

De pizzeria wil de bestellingen ontvangen, bereiden en bezorgen via een webapplicatie en app. 

Op basis van deze wensen kom je tot een landschap van vier applicaties (de blauwe blokken) met overeenkomende functionaliteiten (de grijze blokken), zie de afbeelding:

Naast de applicaties zullen er ook vier backend services nodig zijn, zie de afbeelding:

Pizza Service, heeft als doel om bestelbare pizza’s terug te geven;

Topping Service, heeft als doel om de toppings voor een specifieke pizza terug te geven;

Payment Service, heeft als doel om de afhandeling van de betaling te regelen;

Order Service, heeft als doel om bestellingen binnen te krijgen en te verwerken.

Sommige functionaliteiten maken gebruik van meerdere services, maar er is vanuit de functionaliteit gezien altijd maar één ingang/startpunt. Voor de functionaliteit “overzicht” zal enkel de “pizza service” benaderd worden, eveneens voor de functionaliteit “samenstellen” welke de “topping service” gebruikt. Bij de functionaliteit “bestellen” wordt het al een stuk interessanter. Om de pizza’s te kunnen bestellen zal dit via de “order service” verlopen. Omdat je natuurlijk eerst moet betalen, zal er vanuit de “order service” een beroep gedaan worden op de “payment service” zodat de betaling gedaan en geverifieerd kan worden. De functionaliteit “bestelstatus” zal via de “order service” verlopen.

Voor de consumenten zijn de ingangen naar de services voornamelijk via de “pizza service” en “topping service” om vervolgens te bestellen via de “order service”. Vanuit de CINQeria is de ingang voornamelijk de “order service”. Deze laat ons namelijk weten welke orders er zijn geweest. In een order staat onder andere informatie welke pizza’s er zijn samengesteld en of de betaling succesvol is gedaan. Om de functionaliteit “orders” en “bereiden” te kunnen doen zal de “order service” als startpunt worden genomen. Deze haalt vervolgens weer informatie op uit de andere services. Voor de consument als de CINQeria ziet het er dan ongeveer zo uit:

De communicatie van en naar services kan je op allerlei manieren optuigen. De belangrijkste regel die je moet onthouden is dat elke service zijn eigen doel heeft. De “order service” heeft (data)-afhankelijkheden van alle andere services, maar het doel is nog steeds het geven van informatie over de order. Je kunt het zien dat elke service een contract heeft voor input en output. Dat wil zeggen dat de inhoudelijke informatie van de order wordt opgehaald uit de andere services. In de “order service” staat informatie over welke pizza ID’s en bijhorende topping ID’s. Idem van de betalingstatus. Door middel van contractbeheer (schema’s definiëren, contracttesting, etc) hou je grip op wat erin en uitgaat. De data kan je bijvoorbeeld laten lopen via message queuing en het ophalen van data via GraphQL. Ook wil ik gelijk benadrukken dat alleen dit al een vak apart is tussen services.

Naast de services weten wij ook dat De CINQeria meerdere applicaties gaat gebruiken. Zo heeft elke applicatie zijn eigen gebruikers, zijn eigen doel en eigen platform. Door hier zo slim mogelijk over na te denken kom je tot een wens om een aantal dingen vast te leggen, dit zijn een Design System en Styleguide, gedeelde componenten en gedeelde functionaliteiten. Omdat allemaal te bereiken maak ik een keuze die wel toekomst vast is, maar waarin je nog wel de mogelijkheid om keuzes te maken.

Voor de CINQeria wil ik zo min mogelijk ontwikkelen en een zo groot mogelijk bereik hebben via verschillende platforms. Daarom kies ik voor een Design System uit Webcomponents (gemaakt via StencilJS) en een gedeelde library waarin ik dezelfde (deel)-functionaliteiten heb. Dan kan je ongeveer op zoiets uit:

De gedeelde library wil ik ontwikkelen met Angular, zodat de meeste applicaties hier slim gebruik van kunnen maken. De mobiele applicaties wil ik bijvoorbeeld ontwikkelen met Ionic in combinatie met Angular. Op deze manier heb ik samenwerking tussen het Design System, de gedeelde library en de applicatie zelf.

De blauwe blokken zijn nog steeds de applicaties en de oranje blokken beschrijven op welke manier. Binnen deze applicaties wordt gebruik gemaakt van de donkergrijze blokken, wat dus gedeelde functionaliteiten zijn die op hun beurt weer gebruik maken van het Design System. De lichtgrijze blokken zijn ook functionaliteiten, maar binnen de applicatie zelf. Ook deze componenten maken weer gebruik van het Design System. 

Door middel van dit artikel hoop ik jullie een klein beetje meegenomen te hebben in de wereld van microservices in combinatie met Micro Frontends. Zogezegd, zo gedaan. Ten tijde van dit artikel wist ik natuurlijk op voorhand al ongeveer wat ik wilde gaan schrijven. Toch heb ik hier en daar wat moeten aanpassen in de blokjes van functionaliteiten en services om het verhaal beter over te brengen. De belangrijkste conclusie die ik kan meegeven is keep it simple en hou vast aan het doel van de service of applicatie. Hoort dat echt bij die service of wordt het op nog meer plekken gebruikt? Is het daarom reden voor een eigen service? Maar let op; blijf bij de les. Het landschap aan services groeit snel, dus zorg altijd dat je het onder controle hebt met contractbeheer en testing. Een gewaarschuwd mens telt voor twee.

Een landschap van microservices uit applicaties (van frontends) die ontwikkeld zijn als een verzameling van applicaties (dus functionaliteiten).

De CINQeria; een wereld van microservices en frontends

In een eerder blogartikel benadrukte ik dat een native app ontwikkelen lange tijd gezien werd als een must. Ik legde de nadruk op de keuzes die je kan maken om de juiste beslissing te kunnen maken. Daarin had ik mij voorgenomen om niet specifiek te richten op de mogelijkheden van native apps. Voorheen werd specifiek ontwikkelen voor Apple of Android als ‘lastig’, ‘duur’ en ‘veel tijd’ ervaren, omdat je dit moest doen in verschillende talen; namelijk Swift en Java/Kotlin. Om dit probleem op te lossen heeft Google een cross-platform gelanceerd genaamd Flutter. Is Flutter daarmee de toekomst van cross-platform native apps?

UI-toolkit voor native compiled applicaties voor mobile, web en desktop

Flutter zet zichzelf in de markt als een UI-toolkit om native compiled applicaties te ontwikkelen voor mobile, web en desktop. Dit doe je door middel van een single codebase, wat wil zeggen dat je één stuk code hebt wat zich laat compileren naar de specifieke platformen die jij wenst. Om een Flutter app te ontwikkelen zal je de (vrij) nieuwe programmeertaal Dart je eigen moeten maken. Flutter leent zich ervoor om snel te ontwikkelen door Stateful Hot Reload en ben je de baas over elke pixel van de applicatie. 

Dart lijkt enigszins op een combinatie tussen Java/C# en Javascript. Het verdeelt zichzelf over drie verschillende eigenschappen. Een geoptimaliseerde UI, productieve development ervaring en snelle performance op alle platformen. Dart is – volgens wat zij zelf schrijven – makkelijk om te leren. Je kunt gemakkelijk code (on)afhankelijk van elkaar maken. Door middel van je eigen editor kan jij dingen als debugging snel voor elkaar krijgen. Ook passen zij AOT-compile toe om zo de juiste performance ervaring te bereiken. 

Voor meerdere platformen (snel) ontwikkelen vanuit een single codebase

Ook mogelijkheid tot het compileren van een native desktopapplicatie

Voorzien van een herkenbare/vergelijkbare architectuur

Beschikbare widgets zijn getest en makkelijk te gebruiken

Dart-code het meest dicht bij het native platform

Regelmatig breaking changes, onderhoud kan een uitdaging zijn

Geen mogelijkheid tot specifieke UI voor verschillende platformen

Programmeren in Dart vereist een leer curve, maar makkelijk te leren

Niet volledige mogelijkheden kunnen benutten van de telefoon

Niet de eerste keuze voor kleine apps (compileert veel)

Als je kijkt naar de voor- en nadelen, dan zie je gelijkenissen met andere hybride frameworks. De juiste keuze hangt af van ervaring, doelen en vereisten. Flutter zou ik overwegen wanneer de focus echt ligt op performance. Het is hoe dan ook sneller dan oplossingen die door middel van een webview wordt geladen. Door de vele breaking changes zou ik eerder neigen bij grotere apps voor een andere oplossing (bijvoorbeeld React Native) te kiezen. Het heeft – net als vele anderen frameworks – zeker potentie. Nogmaals verwijzend naar mijn eerdere blogartikel, voeg daarbij Flutter zeker toe als optie.

Lost Flutter het probleem op om niet meer per platform te hoeven ontwikkelen? De mogelijkheden zijn er, maar is Flutter de toekomst?

Flutter, de toekomst van cross-platform native apps?

Is Flutter de toekomst van cross-platform native apps?

Soms vraag ik mijzelf wel eens af of ik energie moet blijven steken in de verschillende frameworks, in het bijzonder Angular. De wereld gedraagt zich zoals deze gevormd wordt door ons als ontwikkelaars. Er is altijd wel weer wat nieuws, maar hoe zorg je dat je op de hoogte blijft van alles? Als ervaren front-end developer probeer ik bij te blijven in deze ontwikkelingen, maar pin ik mij niet vast aan een bepaald framework. Simpel gezegd leer ik de concepten van het ecosysteem van de frameworks en focus ik mijzelf altijd op de native kant van Javascript.

Terug naar het onderwerp; Angular. Om met de deur in het huis te vallen is het (nog steeds) een keuze die je als organisatie kan maken. Het framework is niet uitgestorven in tegenstelling wat je sommige soms hoort zeggen. Kijk je puur ter vergelijking van de downloads via NPM dan heeft Angular niet gewonnen en niet verloren. Op basis van de sterren kan je bepalen of iets populair is, daarin blijft Angular achter ten opzichte van een React of zelfs Vue. Het aantal issues is bij Angular vele maler groter dan bij de andere frameworks. Het biedt meer, dus er zijn meer bugs of feature requests.

Een aantal jaar geleden heeft het team van Angular besloten om elk halfjaar met een nieuwe versie (major) te komen. Sinds de eerste stabiele release medio 2016 zitten wij anno 2021 op versie 12. Hoewel het als major-release wordt uitgerold bevatten deze nauwelijks breaking changes. Door middel van de update guide kan je gemakkelijk van versie 6 naar 8 of van 8 naar 12 updaten. 

De ontwikkeling van Angular staat allesbehalve stil. Dat zie je vervolgens ook terug in de verbeterpunten en functionaliteiten die zijn toegevoegd. In versie 6 was de belangrijkste changes om de meest gebruikte third party packages eveneens mee te laten bewegen in de update cycles van Angular. Vanaf versie 8 stond performance en bundle sizing centraal, waar je in versie 9 het alom bekende ‘Ivy compiler and runtime’ als standaard werden gesteld. Last but not least in versie 12 hebben zij onder andere gewerkt aan het (beter) beschikbaar maken van libraries zodat functionaliteiten herbruikbaar kunnen zijn.

Als laatste punt waar ik stil bij wil staan is dat Angular een duidelijke roadmap beschikbaar heeft gemaakt. Momenteel zijn zij bezig met het versnellen van de unit test tijden. Kijk je verder naar waar zij nu mee bezig zijn, dan zie je daar een aantal interessante dingen op staan als bijvoorbeeld het verbeteren van toegankelijkheid van de components of het bijwerken van de end to end test strategie.

Mijn conclusie is dat Angular heel veel in zich heeft waarbij je ook voor de komende jaren prima mee vooruit kan. Dat wil niet zeggen dat het altijd de keuze is die het meest aansluit. Er zijn genoeg redenen (tijd/budget/kennis/doel/organisatie) om te kiezen voor een ander framework, dat zijn voor mij ook de belangrijkste redenen om mij te blijven verdiepen. Zoals ik eerder al schreef. Er is voor mij geen bepaald framework wat voor mij het belangrijkste is, zolang ik maar de context en concepten van de andere frameworks maar niet vergeet. Bijvoorbeeld dat de CINQ-website is ontwikkeld met Next.js en Prismic. Stay informed, je bent nooit te oud om te blijven leren!

Wat is de toekomst van Angular? En waarom gebruik ik het nog? Het blijft (nog steeds) een optie.

Waarom ik nog steeds Angular gebruik, maar ook andere frameworks niet vergeet

In 2021 Java celebrates its 25th anniversary. As part of this anniversary Oracle offered to register for the Java SE 11 Developer exam for only 25 dollars (22 euros). This is an interesting offer, because normally this will set you back ten times as much. So I decided to go for it and to give it a shot. This offer was valid for two months, so there was a deadline to keep me focussed on my goal. In this blog I will give you some tips to pass this exam.

Before I get to this a little bit more background on myself. I did the Java 8 OCA exam in 2017 (so four years ago). Please note that this was the OCA version. The OCA version is a lot simpler than the OCP version. It will test you on far less topics. The Java SE 11 Developer is comparable to the former OCP versions.

Because of my previous experience I already knew about the kind of questions you can expect. The questions are, to put it mildly, misleading. The exam tries to trip you up with really obscure notations and almost correct options. To give an example, does the following line compile?

public static void main (String []args) {}

All Java developers recognise this as the main entrypoint of a Java program. Most developers will frown their brows on the part between the parentheses. Normally we see one of the following:

I had never seen String []args before, but apparently it is allowed, so it does compile. Most questions contain several of these “interesting” cases.

So to pass this (or any other Java exams) you have to become a human compiler. You need to know if code will compile or not. Half of the questions have an option that says the code will not compile. 

The first question is: Where should I start? 

Tip 1 - OCP Java SE 11 Developer Complete Study Guide

I used and recommend the Oracle Certified Professional Java SE 11 Developer Complete Study Guide from Jeanne Boyarsky and Scott Selikoff. This book has around 1300 (!) pages, but it has all the information that you need. It has the depth that you need to become the aforementioned human compiler. Furthermore it is also brimming with questions to test your knowledge and sharpen your skills. 

This book also comes with an online test environment in which you can customize the kind of exam you like to do. For instance you can specify that you only want questions about exceptions or security. You can also create an exam with only x questions or one that only contains questions that you incorrectly answered in the past. A great tool to prepare effectively. 

Tip 2 - Do not underestimate the difficulty of this exam.

The exam was much more difficult than I expected when I started this adventure. It took far more time and effort than I had planned to commit to this. In the intro of this blog I mentioned passing for the OCA 8 exam. I had to study quite a lot for this exam, but leading up to the exam I was pretty confident that I would pass. For this exam I studied thrice as hard and I could not predict the outcome. So in the end I put in about 120 hours to fail at my first attempt. 😞

Tip 3 - Practice a lot (and then even more)

After spending sixty hours on studying I took my first mock exam and I failed gloriously. I only answered 40 percent of the questions correctly. The exam asks really in depth stuff, so for me just studying was not enough. I had to practice and practice to familiarize myself with all the nooks and crannies of the Java language. So I spend another sixty hours doing as many practice questions and mock exams as humanly possible. I had to do the exam twice and I barely passed it the second time. 

Tip 4 - Look at the answers before reading the rest of question

All previous tips are about preparing for the exam. The last tip will be about the exam itself. It consists of 50 questions and you have to answer them in 90 minutes. That is 108 seconds per question. That is a scary little amount of time when you have to parse 15 lines of code. Normally you start with checking if the code compiles. So you start looking for compile errors. Once you have done that you try to understand what the code does. The code will not be straight forward. There will be strange constructs in there. There will be things that do not make sense in the real world. Finally you have to find the correct answer. This is a pretty tall order to complete in 108 seconds. Actually I was not able to do it consistently. So I had to change my approach. 

I started looking at the answers before I read the question and this really sped me up. Maybe there is no answer option that says that it does not compile. So you do not have to check for compile errors. Maybe there is an answer option that says it will give a compile error at a given line. Now you can check this line for obvious errors. These are only two examples, but you can get a lot of information from the possible answers. So use this information to your advantage to get the correct answer faster. 

Thank you for reading this blog and good luck passing the exam!

Update February 2022: Check out Ian van Nieuwkoop's new blog with Four more tips to pass the Java SE 11 Developer exam.

The Java SE 11 Developer exam is a tough cookie. Read our 4 essential tips to help you pass the exam.

4 Tips to pass the Java SE 11 Developer exam

We schrijven allemaal wel eens code die op een later moment een punt van frustratie wordt voor onszelf, of onze collega’s. Soms copy-paste je een stuk code (dupliceren) en komt het er niet van om dit op te schonen. Of je maakt een ontwerp beslissing die in eerste instantie goed lijkt, maar waarvan later blijkt dat het een tijdrovende fout is geweest. 

In deze blog zal ik twee grote frustratiepunten beschrijven, met de focus op Java, wanneer je code probeert te veranderen: dupliceren (copy-pasten) en het onnodig koppelen (coupling) ten gevolge van overerving (inheritance). 

Het kan erg frustrerend zijn wanneer je denkt klaar te zijn met het aanbrengen van een verandering, om er dan achter te komen dat je dezelfde verandering op een tiental andere plekken in je code moet herhalen, voordat het goed zal werken. 

Tijdens het ontwerpen van een systeem, zou je altijd het DRY principe moeten volgen: Elk stukje kennis moet een enkele, eenduidige, belangrijke vertegenwoordiging hebben binnen een systeem. Echter, betekent dit niet dat elke identieke regel tekst of code een duplicaat is. Het kan ook gewoon zo zijn dat de implementatie identiek is. 

DRY gaat over het dupliceren van kennis, die onder andere voorkomt in:

Vaak vergeet men dat documentatie ook geüpdatet moet worden, samen met de veranderingen die je maakt aan je codebase. Het enige wat erger is dan geen documentatie, is verkeerde of verouderde documentatie. Verouderde documentatie kan misleidend zijn en kan je een hoop extra werk kosten. 

Commentaar, of ‘comments’, is slechts een andere vorm van duplicatie. Functies en variabelen met duidelijke namen hebben geen comments nodig. Comments binnen methodes zijn een teken dat de methode te lang is. Deze zouden opgedeeld moeten worden in aparte methodes, met duidelijk beschrijvende namen.

Developers die niet weten wat hun teamgenoten aan het bouwen zijn, lopen het risico om vergelijkbare code te schrijven. Hierdoor dupliceren ze onbewust functionaliteit die al bestaat. Dit kan alleen worden verminderd door betere communicatie. Actieve en frequente communicatie tijdens de dagelijkse stand-ups, forums, etc. Het is dan ook verstandig om de source code en documentatie van anderen te lezen tijdens code reviews of informeel. 

En dan nu: duplicatie in code. Het is het beste om klein te beginnen met het verwijderen hiervan. Allereerst lokaliseer en verwijder je kleinere stukjes gedupliceerde code in aparte methodes. Hierdoor wordt het makkelijker om daarna de grotere stukken van gedupliceerde code te lokaliseren en verwijderen. Vergeet niet om test units te draaien na elke grote verandering, zodat je niet elke keer te veel werk moet terugdraaien. 

Verplaats gedupliceerde code van verschillende klassen, naar zijn eigen klasse.  Na het verwijderen, moet de nieuwe klasse gekoppeld worden aan de klasse die gebruikt wordt. In Java heb je twee opties:

• Optie 1:een 'has a'-relatie. De originele klassen kunnen een fractie van de nieuwe klasse krijgen als een private attribute. Dit wordt ook wel composition of delegation genoemd, omdat je functionaliteit delegeert aan componenten van een andere klasse.

• Optie 2: Een "is-a" -relatie. De originele klassen kunnen de nieuwe klasse uitbreiden.

Het belangrijkste om rekening mee te houden wanneer je een implementatieoptie kiest, is: Erfbelasting. Je moet nog een verandering maken en denkt dat je klaar bent. Maar helaas, je komt erachter dat je zojuist de code op een tiental andere plekken hebt gebroken, omdat meerdere klassen sterk met elkaar gekoppeld zijn.

Gelukkig zijn er een aantal goede methodes als het gaat om het verminderen van onnodige koppelingen. Eén daarvan is: Betaal geen erfbelasting. Inheritance/overerving is een vorm van koppeling en moet dus vermeden worden indien mogelijk. 

Waarschijnlijk is dit niet wat je geleerd hebt. Inheritance gebruiken voor gedragssamenstelling en polymorfisme is een gangbare praktijk die je in elk OOP-handboek aantreft. In de praktijk heeft het echter een aantal ernstige nadelen.

Allereerste: dit zul je je misschien niet realiseren, maar wanneer een klasse is overerft, ontstaat er koppeling tussen meerdere concrete classes. Een kind klasse is gekoppeld aan een ouder klasse, een "grootouder klasse" enzovoorts. Maar elk object dat dit kind klasse gebruikt, is ook gekoppeld aan al zijn voorouders. 

Ten tweede: in een beperkt domein is het logisch dat een auto een soort voertuig is. Maar zodra het domein waarin je werkt gecompliceerder en realistischer wordt, worden deze modellen complexer en bijna onmogelijk te vormen. Bijvoorbeeld: wat gebeurd er wanneer een auto ook een soort eigenvermogen, te verzekeren object, etc. is. In dit geval heeft de auto dus meerdere overervingen nodig. Dat is niet alleen onmogelijk in sommige talen, zoals Java, maar indien het wel mogelijk is, eindig je vaak met complexe modellen die je alleen maar hoofdpijn bezorgen. 

Onze laatste blogs over Development