Changes in visibility

Java has always had the visibility modifiers public, protected, default, and private, in descending order of access. This is still effective with the same rules within a module. However the module boundaries add an extra line of visibility defense. A public element from module A is only visible to elements in module B if the public elements is part of an exported package. As far as reflection goes. An element in module A is accessible via reflection only if the package of the element is open (with the opens keyword) either globally or explicitly to module B ( e.g. module A { exports aPackage to B;}).

Black box vs White Box

In testing, one distinguishes between so called black box and white box tests.

Black box in this respect means that you cannot see the internals, but only those parts defined in the API. This is the way that a client package will use the API. Black box testing is easily supported by the module system, because the test classes behave as ordinary clients.
White box would better be called transparent box, but the name white box stuck. In white box tests you DO want access to the (package) private parts of your business code. This is a bit handicapped by the way the JPMS allows access.

Standard Source code organization.

src
├── main
│   └── java
│       └── genericdao
│           ├── dao
│           ├── memory
│           └── pgdao
└── test
    └── java
        ├── genericdao
            ├── dao
            ├── memory
            └── pgdao

We are using maven, in which the unit test plugin is called surefire, the integration test plugin (which we did not use up to this point yet) is called failsafe.

The standard way source code is organized is by means of separate directories for the 'business' code and the test code in two separate directory trees inside the same project.
This practice, which prevents test code to land in the final application or library jar file is useful, so we will keep it as it is.

However, JPMS does not allow so called split packages. Surefire addresses this problem by telling the JVM to patch the module we are testing with the classes defined in the test source tree. It is as if the test classes are put in the business source tree.
This allows the test classes access to the package private parts of the classes, the way it worked in before JPMS.

module nl.fontys.sebidao {
    exports nl.fontys.sebivenlo.dao;
    exports nl.fontys.sebivenlo.dao.memory;
    exports nl.fontys.sebivenlo.dao.pg;
    requires java.logging;
    requires java.naming;
    requires java.sql;
    requires org.postgresql.jdbc;
}

The module definition above exports three packages and declares itself dependent on 3 modules from Java API and one postgresql module.

Unit tests, and in particular the testing libraries such as AssertJ, and Mockito use reflection to do their work. The simplest example is JUnit itself, which uses reflection to read the annotations in the class file. So does Mockito. AssertJ uses reflection to get to fields (for deepEquals) and methods. Reflection is a tool very sharp indeed, to get to the guts of the System Under Test. Of these Test libraries JUnit and AssertJ have module definitions already. Mockito and postgresql do not have that at the time of writing this document (April 2020).

The quickest way to allow the testing tools access is to fully OPEN the packages of the SUT to world. Because this happens during testing, surefire is instructed to tell the jvm (java), that runs the test, to open those packages to the world. The snippet from the maven pom file that realizes that is given below. You can copy and adapt it for your own purposes.

<properties>
  <surefire.opens> 1
    --add-opens nl.fontys.sebivenlo.genericdao/genericdao.dao=ALL-UNNAMED 2
    --add-opens nl.fontys.sebivenlo.genericdao/genericdao.memory=ALL-UNNAMED
    --add-opens nl.fontys.sebivenlo.genericdao/genericdao.pgdao=ALL-UNNAMED
    --add-opens nl.fontys.sebivenlo.genericdao/usertypes=ALL-UNNAMED
    --add-opens nl.fontys.sebivenlo.genericdao/entities=ALL-UNNAMED,genericmapper
  </surefire.opens>
  3
</properties>

Of particular importance, and project specific are the --add-opens commands, which you must adapt to your own project’s pom file with your own module and package names.

Opens is the most powerful way of exporting a package. It allows full access (as in exports) plus reflection. We could try to make more specific export lines such as --add-export, but although more precise, that will not help very much, because the access enabling lines will only take effect during the (surefire) unit tests.
If you have failsafe integration tests, you will have to do the same for the failsafe plugin, although failsafe tests should stick to black box testing, where such can opener style configuration should not be required.

<S.H.A.P.E.> of java.util.functions

The java.util.functions package, which was introduced in Java 8, contains only functional interfaces and nothing else. The package contains the most common shapes of functions that may occur in lambda expressions. You can see that all reference type functional interfaces heavily rely on generics. The use of the proper generics definition is essential for functional interfaces to function properly.

We will use the notation <input type> → <result type> for the shape of a Functional interface. Note that the shape is determined by the one (abstract) method of the functional interface. The style used in java.util.function is somewhat mnemonic in choosing the generic type parameters in the type interface type definition.

There are also a few specialized interfaces that deal with the primitive types int, long and double. Their rationale is performance and memory footprint, in short: efficiency. Dealing with e.g. arrays of primitive types is much more efficient than using the associated wrapper types, int vs Integer. You save the object allocation memory-wise and the dereferencing and unwrapping execution time-wise.

The package documentation makes an interesting read.

Exceptions in Lambda expressions need special consideration. In particular checked exceptions actually counteract the conciseness of lambda expression. In those cases, where the lambda expression or reference method throws an exception, that exceptions is commonly wrapped in an unchecked exception, e.g. UncheckedIOException to wrap an IOException. UncheckedIOException has been introduced in Java 8 for just that purpose.

You can also roll your own.
If you need to declare a functional interface that potentially throws an exception, the following is a way to do that:

interface ThrowingBiFunction<T,U, R,<X extends Throwable>> {
    R apply(T t, U u) throws X;
}

Shape wise it looks like <T,U> → R | X pronounced as from T and U to either, R the result, or X, the thrown exception.

Where is toString?

You might miss toString() on lambda expressions, and you would be right: Lambda expressions lack a useful toString. What you get by calling toString() on a lambda expression is something rather useless, concocted by the JVM.

Comparator<Student> gradeComp =
      (a,b) -> Double.compare(a.getGrade(),b.getGrade());

When you invoke toString() in say jshell, you get.

jshell> class Student{ double grade; double getGrade(){return grade;}}
|  created class Student

jshell> Comparator<Student> gradeComp = (a,b)
    -> Double.compare(a.getGrade(),b.getGrade());
gradeComp ==> $Lambda$16/0x00000008000b3040@1e88b3c

jshell> gradeComp
jshell> gradeComp.toString()
$3 ==> "$Lambda$16/0x00000008000b3040@1e88b3c"

Method References

Since the shape of a functional interface has everything a method definition has, bar its name, it should be no surprise that this can be used to advantage. Everywhere where a functional interface is allowed you can also provide a so called Method reference. Quite often, but not always this can be a shorthand and thereby improving readability.

Method references have two parts, separated by two colons: ::.

There are four kinds of references:

SQL like functions

select sum(salary)
from   people
where  gender = 'FEMALE'

    int womensPay =
        people.stream()                                         1
            .filter(p -> p.getGender() == Person.Gender.FEMALE) 2
            .mapToInt(p -> p.getSalary())                       3
            .sum();                                             4

    int womensPay =
        people.stream()
            .filter(p -> p.getGender() == Person.Gender.FEMALE)
            .mapToInt( Person::getSalary )                      1
            .sum();

Improved Map in Java 8

I personally find the java.util.Map quite interesting because it got a number of very cool features in Java 7 and 8 that are really very helpful if you want to implement things like caches. If you are into caching and expect many entries, consider a WeakHashMap, that also helps to solve the problem of keeping the cache small and auto-evacuate when entries are no longer used.

In order of appearance in the api doc:

    map.forEach((k, v) -> System.out.println(k + "=" + v));

The fun thing is that all these methods are default methods, so they apply to all classes that implement the java.util.Map interface, including the ones you roll yourselves, might you feel the inclination. To implement a special map that has specific extra properties, you only need to extend AbstractMap which needs the implementation of one or two methods only, depending if you want an unmodifiable of modifiable one.

JPMS

Lambda and streams