Libera #java

Bob Martin, also known in the industry as “Uncle Bob,” wrote a blog post entitled “Make the Magic go away,” which focuses mainly on whether you need a framework, and some minor thoughts about how you might judge.
It’s an interesting article. It uses rxJava as a launching point for thought, using Bob’s own history in the industry as observation (of the Observation Pattern, of all things).
There are some lightning-rod statements:

The authors of rxJava, and of Spring, and JSF, and JPA, and Struts, and [put your favorite framework here] are all searching for the same thing. These frameworks are born out of frustration with the language; and are an attempt to improve upon that language.
Every framework you’ve ever seen is really just an echo of this statement:
My language sucks!
And so we write frameworks to compensate for the lack of features that we wish were in our language.

It’s fair to say that this is hyperbole (and Bob knows it) – a point exaggerated

(by Eron Gjoni, rufsketch1#gmail.com)
packr is a useful little program that allows you to include a copy of the JRE along with your runnable JAR file. Making it much easier for your users to just download and run your program, without them having to worry about java versions or installation procedures. You can learn to use packr from the documentations available on its github page
https://github.com/libgdx/packr
Notably, however, packr requires platform specific copies of the JDK in order to bundle a JRE with your program. This is fine if you have easy access to each of the platforms you wish to support, or if you intend to use openJDK. But what do you do if you only have linux, but want to create a self contained runnable for OS X users? Oracle only provides the OSX JDK as a dmg. Luckily, we can still access the files we need!
Download a copy of the Java SE JDK for OS X from Oracle.
use 7zip to extract the contents of the .dmg.

7z x jdx-[version number]-x64.dmg -oosxJDK

cd into the osxJDK subdirectory created by the command above.
You’ll see a number of files that were extracted from the dmg.
We’re interested in the contents of the file ending in .hfs.
To access its contents, first make sure you have the hfsplus module active.

sudo modprobe hfsplus

Then, create a subdirectory into which to mount the .hfs file.

mkdir mountedHFS

Then, mount the file

mount -oloop 4.hfs mountedHFS

If you cd into the mountedHFS directory, you will find a .pkg file. Move it to the parent directory and then unmount the .hfs file.

sudo mv JDK\ 8\ Update\ 131.pkg ../ && cd ../ && sudo umount mountedHFS

Next, extract the contents of the .pkg file into a new subdirectory.

7z x JDK\ 8\ Update\ 131.pkg -opkg

cd into that subdirectory

cd pkg

You will find a number of files and subdirectories. cd into the jdk180131.pkg subdirectory (replacing the version number as appropriate)

cd jdk180131.pkg

There you will find a file named Payload. We will need to extract the contents of this file using

cat Payload | gunzip -dc |cpio -i

A new subdirectory called Contents will be created. if you cd into Contents/Home you will find the files needed by packr to create a self-contained bundle for OSX.

A user on #java asked how one might invoke a method of a superclass recently, and received some general answers that more or less were right, but weren’t technically correct.

Maldivia pointed out that you would use method handles, which is sort of the gist of the (incorrect) answers given. The attempt was made to invoke the method via getDeclaredMethod(), which does not work.

The way to do it is to use MethodHandles.lookup() to get, well, a MethodHandles.Lookup object, which provides a way to get methods in the context of a class.

First, you’d get a MethodType reference, that refers to the _return value_ of the method. Then, you’d use findSpecial() – as one likely possibility – to find a method by name in a given class.

With that, you’d be able to invoke() the method.

Here’s code showing a superclass – Drink – and a main() in a subclass, Coffee, that has a bad call (the suggestion from the channel, tried and failing) and a good call, based on Maldivia’s suggestion, that actually does invoke Drink.toString() even when called from the context of a Coffee instance.

This is not expected to be held as an example of “what you should do” – for one thing, calling superclass’ methods outside of explicit access from a subclass is terrible design, in most cases, and for another, this is an example designed to run and not run properly or exhaustively. It’s simply a starting point.

import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

class Drink {
    public String toString() {
        return "This is a Drink!";
    }

}

public class Coffee extends Drink {
    public String toString() {
        return "This is a Coffee!";
    }

    static void badCall(Coffee coffee) throws Throwable {
        var method = coffee
                .getClass()
                .getSuperclass()
                .getDeclaredMethod("toString", null);
        System.out.println(method);
        System.out.println(method.invoke(coffee, null));
        System.out.println(coffee);
    }

    static void goodCall(Coffee coffee) throws Throwable {
        MethodHandles.Lookup lookup = MethodHandles.lookup();
        MethodType type = MethodType.methodType(String.class);
        var m = lookup.findSpecial(coffee
                        .getClass()
                        .getSuperclass(),
                "toString",
                type,
                coffee.getClass()
        );
        System.out.println(m);
        System.out.println(m.invoke(coffee));
    }

    public static void main(String[] args) throws Throwable {
        Coffee coffee = new Coffee();
        badCall(coffee);
        goodCall(coffee);
    }
}

A channel member asked if there was a way to do multiline properties in Java, and if so, how was leading whitespace handled?

The answers are, respectively, “yes,” and “pretty much as you’d hope it was.”

The multiline character for Java properties is, as one might expect from every other programming language’s usage, the \ character, and the Properties.load() method will trim all leading whitespace from the property value. Here’s a sample:

// This is Example.java
package example;

class Example {
  public static void main(String[] args) {
    // sorry for the gross formatting here, page width!
    try(var in=Example
      .class
      .getResourceAsStream("/foo.properties")) {
      var properties=new Properties();
      properties.load(in);
      System.out.println(properties.getProperty("foo"));
    }
  }
}

And the properties file, foo.properties, which should be visible in the classpath at the root:

# this is /foo.properties
# note how "multiline" is indented more than the rest
foo = this \
  is \
  a \
    multiline \
  property

If this is run and the classpath is set properly, the output should be this is a multiline property. You can embed newlines with \n as desired as well, if you need those in the output.