Add a java-function-interop library containing common function/tuple datastructures as a Scala module

[mdedetrich]

The Akka codebase contains various interopt datatypes (functions, tuples, partial matchers) which are datatypes that are used within codebases that have heavy Java and Scala interopt. Rather than scala-java8-compat which is designed to convert between Scala and Java8 data types (such as functions), the ones defined by Akka cover cases where either

• No such datatype/abstraction exist's in Java (i.e. partial functions)
• The Java datatype exists however has some limitation which the Scala one doesn't have. i.e. akka.japi.Function is allowed to throw an exception in the apply where as the Java's java.util.function.Function cannot.

There is a sample project at https://github.com/mdedetrich/java-function-interop which already contains a general outline of the module. The project also contains an AUTHORS which details the notable past committers of the contained source files.

Below is an exhaustive list of what data types are copied over from Akka's latest ASL 2.0 snapshot (i.e. https://github.com/akka/akka/tree/6680c47dcc2305906a44d7794081682211d7ee0b)

• akka.japi.Function
• akka.japi.Function2
• akka.japi.Procedure
• akka.japi.Effect
• akka.japi.Predicate
• akka.japi.Pair
• akka.japi.Creator
• akka.japi.JavaPartialFunction
• akka.japi.Function* (boilerplate generated classes)
• akka.japi.Tuple* (boilerplate generated classes)
• akka.japi.pf.AbstractMatch
• akka.japi.pf.AbstractPFBuilder
• akka.japi.pf.FI
• akka.japi.pf.Match
• akka.japi.pf.PFBuilder
• akka.japi.pf.UnitMatch
• akka.japi.pf.UnitPFBuilder

One datatype that is missing from the list is Option. Akka defines its own Option type likely because there are still people pre JVM 1.8 (where no option type exists) Java users which use Akka. I didn't include Option in the list because apart from pre JVM 1.8 Java users it has no utility where as the akka.japi.Function still has notable different behaviour (i.e. supporting throwing of exceptions in apply).

In terms of stability, considering that these data types have existed in Akka for literally a decade (or more) now and Akka having extremely strict MIMA/binary compatibility guarantees, this should be more then enough proof that the datatypes both work and are unlikely need to changed in the future (it would be highly surprising if more than one release per Scala version needs to be made). On a more general note as a community module, this can potentially be very useful for hybrid Scala/Java projects (such as Akka) so that Java users has access to Scala abstractions that do not exist yet in Java. Having commonly defined datatypes also means that said projects can reused the same abstractions rather than every project creating their own (with potential performance impacts of having to convert between the datatypes of the different projects).

[He-Pin]

Vavr has an Option type

[SethTisue]

I've recorded a bunch of general thoughts about the "Scala module" concept over at scala/scala-library-next#137. cc @julienrf

[SethTisue]

One possibility would be for scala-java8-compat to get an expanded ambit and/or a new name, in order for this stuff to fit.