Why do we need JOOL from JOOQ?

Question

Going through JOOL library from JOOQ which provides lots of Functional Interfaces and Utility classes on Streams.

My question is there are 1-16 parameter functional interfaces supported by this library. Do this makes sense at all? As I have always been in a practice to reduce the number of parameters in a method to 3. Though acceptable number varies according to different thought leaders on it. But no one says 16.

See reference links from StackOverflow itself:

what is the standard number of parameters that a java method should have?

Also, it provides a utility class Seq which looks like is limited to sequential processing only.

Can someone with good past experience using JOOL answer why I should be using JOOL as looks like lots of things it contains are of no use?

Answer 1

There is no set number of arguments in a function that I would consider best practice, I think you should use what you need without going to extremes, causing inefficiencies or making your code hard to read. If you find yourself with a function with 10 parameters, think twice if it makes sense (maybe it does).

There are several libraries that use functions that receive 10+ parameters:

• Guava (check this function with 10 parameters)
• jOOλ (check this function with 16 parameters)
• Java 9 (check this function with 20 parameters)

The reasons for this is mainly compile-time type checking. Also you could argue improved efficiency, and perceived cleanliness.

Take for example Guava's of function:

ImmutableMap<K,V> of(K k1, V v1, K k2, V v2, K k3, V v3, K k4, V v4)

which is used like this:

Map<String, Integer> m = ImmutableMap.of("Ashlyn", 127, 
                                         "Abigaile", 128,
                                         "Alexis", 132,
                                         "Ashlynn", 132);

This function, that receives 8 parameters, provides:

Type safety

Because "odd" parameters are checked at compile time to be String and "even" parameters to be Integer). You can't do this with vararg functions because you'll need to declare the varargs parameter as Object..., losing the compile-time type checking.

Efficiency

You could get compile-time type safety by using an intermediate object like:

Map.ofEntries(entry("Ashlyn", 27), 
              entry("Abigaile", 28),
              entry("Alexis", 32),
              entry("Ashlynn", 32))

Which by the way exists in Java 9, but then you would be creating 4 intermediate objects that were not necessary with the 8-parameter version. You would be also creating an extra array object to hold the varargs objects.

Cleanliness

Compare the previous two snippets of code, the inclusion of entry() means more letters to type and read. This can be kind of subjective, but at least I prefer how the code looks without the inclusion of entries.

Why jOOλ?

jOOλ comes into play to account for these Java API deficiencies:

• You have Function and BiFunction but you can't do something like TriFunction<Integer, String, Boolean, Double>. You'd have to sacrifice one of your parameters (or the type safety altogether) unless you use jOOλ.

• Java lacks tuples altogether, you need to use either javatuples or jOOλ, unless you want to sacrifice the type safety again.

• There are other deficiencies in Java's API that are not related to this question but that are addressed by jOOλ like (the one I like the most) having the ability to pass around a lambda that throws checked exceptions.