"Modernize" jinterface - Proposal

[Crain-32]

I use the term "Modernize" Loosely, as the initial target will be Java 8.

I will fully admit to not being an avid Erlang Developer, nor a jinterface consumer, but rather someone that was reviewing jinterface for a weekend side project, and realized it could use some upkeep. Before dedicating myself to doing that though, I figured a proper proposal style issue was in order.

The following are things that I would consider "targets" of a modernization effort, with the "why" of each given below.

Java 8

Per the pom.xml, we currently target Java 6, which is outside both Oracle's and the OpenJDK's support lifecycle. Upgrading jinterface to the minimum supported LTS (Java 8) is good for the Java Ecosystem, and jinterface as a whole.

Behavior Changes

Depending on the outcome of this proposal I'll write up a full review, but the following are examples of what I see as things on the table for an update. The reasoning for updating is simply that in this modernization we should ask ourselves if jinterface is being used in a way that modern Java developers are family with, or if "modern" features can be used to improve the development process.

• GenericQueue, can be replaced with a LinkedBlockingQueue<?>, which is an unbounded thread safe FIFO queue, and since it is handled by Java further updates to later versions is straightforward.
• Refactor Mailbox and Linking
  With Java 8 we can use the java.util.function Package, and with that I propose swapping jinterface to use a more Consumer/Producer style pattern.
  For example,

var node= new OtpNode("example");
var mailbox = node.simpleMailbox(
    HandlerClass::onMessage, // OtpMbox::receive handler if it doesn't throw an exception. `Consumer<OtpMsg>`
    HandlerClass::onError //  OtpMbox::receive handler if it does throw an exception `Consumer<Throwable>`
    );

I think Additional Handlers for RPC could be discussed.

Pom Changes

There are a couple I'd like to propose, with the core idea being to improve the testing and the release process.
Per Issue #7896 , the current owner for the sonatype domain no longer has access. I'm not sure what can be done there, but ideally the community can regain control of the domain and begin releasing to it from a more official capacity. Once a path forward is decided there, more talk could be had around the build/release process and the current plugin configuration.
I'd like to propose the inclusion of SLF4J within the provided scope. This will replace the System.out.println messages found in classes like AbstractConnection, OtpEpmd.
Additional Dependencies for Testing (Mainly JUnit) will be at the "test" scope, and so I'm less concerned if they should be included or not.

Package Restructuring

Currently everything exists within the com.ericsson.otp.erlang package, I propose the creation of 4 new packages
...otp.erlang.erl
...otp.erlang.com
...otp.erlang.exception
...otp.erlang.misc
With more subpackages as deemed appropriate. This targets project navigation and structure, as the current format is rather jarring from an initial viewer's standpoint. The package names and expected classes for them mirror the current java_files structure

Testing Overhaul

Not much to say here besides swapping the tests over to JUnit 5 to align with more modern practices.

It should go without saying, but any of these changes could be considered a major change, and bump jinterface to be 2.X.X in terms of semver.

[garazdawi]

Hello!

We mainly regard Jinterface as an legacy application. That is an application that exists because there are current projects that rely on its existence. Therefore backwards compatability is of utmost importance. We do not want to do any changes that results in users of JInterface to have to modify their code.

With that in mind we do welcome modernization changes that keep backwards compatability, though you will have to be patient with us as none of us are very good at Java (the last time I used it was roughly 20 years ago...) and this area is not of high priority to us.

[Crain-32]

I suppose my first question then would be if upgrading the minimum version of Java is too much due to compatibility concerns. I've dealt with enough Java 8 at work that I'm comfortable using that, but I'm not knowledgeable enough in Java 6 to help if the plan is to stay there for the foreseeable future.