Modern-Java-in-Action

Task appropriate for the job high parallelization : use fork-join pool and and parallel streams for highly CPU-bound calculations high interactivity: high concurrency and a need to keep a lot of IO-bound tasks on single CPU: use Future (Completable Future) or Flow API Problems and solutions Threads problems map 1:1 to OS threads (expensive to create and of limited number) much higher number than hardware threads (cores? well, it seems a core is more complex) CPUs like the Intel i7-6900K have multiple hardware threads per core, so the CPU can execute useful instructions even for short delays such as a cache miss. ...

Chapter 14 is “The Java Module System” and this post is a note that helps to refresh my knowledge about Java Module System. ...

Reasons to abandon old API java.util.Date mutable unintuitive constructor (days, months, minutes and seconds are 0-based, year represented as delta from 1900), values wrap-around cannot be internationalized java.util.Calendar not thread safe mutable (no clear semantics date change) when to use which? java.util.DateFormat not thead-safe can only parse Date, not Calendar New API java.time package Classes and interfaces in a new package java.time (modelled after Joda Time classes) provide better way of thinking about and working with time concepts. The most important classess in this package are: LocalDate, LocalTime, LocalDateTime, Instant, Duration, and Period . ...

Null problem Reasons why null is problematic: source of coding errors (missing checks) does not correctly model absence of value (null has no meaning) breaks Java philosophy of hiding pointers (null is a pointer which is NOT hidden) Handling in other languages Groovy has safe navigation operator Kotlin is known for its null-safety Haskell has Maybe typeclass Scala also has an Option class Optional Creating Three static methods may create instances of Optional: Optional.empty() - creates empty instance Optional.of(T) - returns Optional with given non-null value Optional.ofNullable(T) - returns either Optional with T value or Optional.empty() if value is null java.util.Optional in Java 17 - compared to Java 8 - gains the following: ...

Refatoring Here are three simple refactorings that can be used if you want to migrate your codebase to Java 8 (or higher). You may want to do so for many different reasons (readability, conciseness, code reuse, security). Refactoring anonymous classes to lambda expressions Refactoring lambda expressions to method references Refactoring imperative-style data processing to streams Recommended paper about automatic refactoing of pre-Java 8 codebases into Java8: Lambda Refactoring Gotchas different meaning of this and super (in lambda this refers to enclosing class, in inner class - to itself) lambdas cannot (and anonymous inner classes can) shadow enclosing class variables Code flexibility Question: when to introduce functional interfaces? ...

New API (in Java 8) Collection classes got a few nice additions. Factory methods They create immutable collection (if you try to add/remove elements, you get UnsupportedOperationException. There is no varargs variant - this variant would require additional array allocation, which non-varargs variants don’t have. There are overloads from 1 to 10 elements. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 //static <E> List<E> of(E... elements) static <E> List<E> of(E e1) static <E> List<E> of(E e1, E e2) static <E> List<E> of(E e1, E e2, E e3) static <E> List<E> of(E e1, E e2, E e3, E e4) static <E> List<E> of(E e1, E e2, E e3, E e4, E e5) // ... other variants static <E> Set<E> of(E e1) static <E> Set<E> of(E e1, E e2) //... etc, other variants up to 10 static <K, V> Map<E> of(K k1, V v1) static <K, V> Map<E> of(K k1, V v1, K k2, V v2) // ... etc, variants up to 10 pairs // or with entries import static java.util.Map.entry; static <K, V> Map<E> ofEntries(entry(k1, v1), entry(k2, v2)) lists: removeIf, replaceAll On a list you can use removeIf and replaceAll ...

Second chapter shows how parallellization works with streams; explains what fork-join pool is (which is used by streams framework underneath), what data structures are decomposable, how to create your own spliterator for more effective splitting of source stream for parallel processing. Parallel streams created by a call to parallel() in a chain of stream operations fork/join pool uses Runtime.getRuntime().available-Processors() number of threads by default, but you can change it by specifying java.util.concurrent.ForkJoinPool.common.parallelism system property: 1 System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "12"); Hints measure (check Java Microbenchmark Harness (JMH)) beware boxing/unboxing operations (use IntStream, DoubleStream of FloatStream) limit() and findFirst() are worse on parallel streams (they require order) than findAny() with unordered() don’t use inherently sequential functions: instead of this one, which is not easily parallelisable: 1 Stream.iterate(1L, i -> i + 1).limit(N) you should rather use: 1 LongStream.rangeClosed(1, N) which works on long values (no boxing) and produces easliy splittable range ideal for parallelization. know which data structures are easily decomposable (ArrayList is - it can be split without traversing it, LinkedList isn’t) performance depends also on order of stream operations which may change stream characteristics (SIZED stream can be split, filtered stream has unknow number of elems) note the cost of terminal operation (if high - parallel time gain can be smaller that time used for combining partial results) Decomposability table class composability ArrayList 😄 Excellent IntStream.range 😄 Excellent HashSet 😐 Good TreeSet 😐 God LinkedList 😭 Bad Stream.iterate 😭 Bad Fork Join pool ForkJoinPool is an implementation of ExecutorService requires creation of a RecursiveTask subclass with protected abstract R compute(); to use it, use following algorithm: 1 2 3 4 5 6 7 8 if (task is small enough or no longer divisible) { compute task sequentially } else { split task in two subtasks call this method recursively possibly further splitting each subtask wait for the completion of all subtasks combine the results of each subtask } remember: join() is blocking, so use it after results of subtasks are ready as a RecursiveTask, use compute() and fork(), don’t use the invoke() on a pool wisely decide the criteria if the task should be split further (see example in a javadoc for RecursiveAction class where getSurplusQueuedTaskCount() is used for the criteria) subtasks should take longer than creation of a new task it is hard to debug (as with all multithreaded programs) it is hard to measure, due to the fact that fork-join should be warmed-up Work stealing goal: ensure even distribution of work between threads each thread in the pool keeps doubly-linked list of tasks to execute, takes one by one from the head and executes if no more tasks it thread’s onw queue, it randomly selects a thread with no-empty queue and steals a task from the tail of that queue Important You don’t have to use fork-join if your datastructure is decomposable; you just use parallel data streams. Automatic way of traversing a source and splitting it is “spliterator” - the interface which standard collections implement in the default implementation. ...

This post starts Java 8 refresher series - I will keep here my short notes during reading “Modern Java in Action”. ...