JCP party online today vs a year ago

Today was the JCP (Java Community Process) party online for the second year in a row due to the pandemic. I found it interesting comparing how I felt about it between the two years. The format was roughly the same – a welcome, a game, chatting.

Engagement

I felt way more engaged this year. Most of that was due to me. Big group things aren’t that easy to participate in. And last year, I got frustrated more easily. So I got talked over the first few times I tried and gave up. This year, there were either less people or quieter people or I was thinking faster. But it didn’t become a negative feedback loop. And last year because of that negative feedback loop, I felt like I was watching others the whole time.

Paying attention

Way better this year. Working from home all day (and every day) sapped my energy. I didn’t have enough to get through an 8 hour work day let alone enough focus for an after work activity.

Convenience

Last year wins on convenience. I was home all day last year so I just had to walk a few steps and turn on my personal computer. This year, I had to leave work at 3pm. (Which worked out well because I got a new computer and setting i up at home does work well. Start downloads/installs and walk away. I don’t need to watch Maven “download the internet.”

And yes, I could have worked from home today. I didn’t want to. I’ve worked from home enough for a long time.

Human Interaction

A year ago, my interactions were limited to four families and one neighbor. This meant there were some weeks where I’d see one or human beings. That wasn’t enough. So interacting with people online was a constant reminder of how frustrated I was of the fact. This year, I’m going to the office every day and getting out of my apartment. I’m going places and seeing people again. So while I wish I could have seen some of the party attendees in person, it wasn’t a big deal. Also, I’ve seen a few of them in the past few months in person. (I went to KCDC and the NYJavaSig leaders did a get together.)

Overall feeling

The difference a year makes. This proves that environmental surroundings matter.

why java records aren’t quite immutable

A new type called a “record” was previewed in Java 14 and released in Java 16. One of the benefits is that it creates immutable objects. Kind of.

An immutable record

This is record is an immutable object. Since it is a record, it is automatically final and has no setters. All is good.

public record Book (String title, int numPages) { }

A mutable record

There there is this record. Do you see why it is mutable?

public record Book (String title, int numPages, List<String> chapters) { }

The problem is that records use shallow immutability. The caller can’t change the “chapters” object to a different reference. The caller can change the values in the “chapters” to their heart’s content. That means this object is still mutable.

Here’s an example showing that the code prints [1, 2, 3] and therefore changes the list of chapters.

List<String> chapters = new ArrayList<>();
chapters.add("1");

Book book = new Book("Breaking and entering", 289, chapters);

chapters.add("2");
book.chapters().add("3");
System.out.println(book.chapters());

Making the record actually be immutable

It’s pretty easy to make the Book record actually be immutable. In fact, it only requires three extra lines! Records have a compact constructor which takes care of the setting fields for you. However, you can choose to change that behavior. In this example, I rely on the default set of “title” and “numPages”. However, for “chapters”, I choose to make an immutable copy to prevent changing the list.

public record Book (String title, int numPages, List<String> chapters) {

    public Book {
        chapters = List.copyOf(chapters);
    }
}

Now the test program fails with an UnsupportedOperationException. Much better. A real immutable record.

Setting java aliases with zshell on Mac

When I’m working on different versions of Java, I set up a bunch of aliases so I can run commands quickly and compare differences. I recently upgraded my Mac and accepted the default shell as zshell instead of bash. (This change was made a long time ago but I didn’t upgrade for a long time because I didn’t want to incur the risk of being without my computer when everything was closed for the pandemic.)

Since I needed to move this from .bash_profile to .zshenv, I took the opportunity to shed a lot of them. I now have just Java 11 and Java 17 that I am using for comparisons. (LTS to LTS).

My .zshenv now contains this. (Yes, I know I should have patched Java 11, but alas.) I ran “source .zshenv” and am good to go.

Now I can run java11 JeanneTest.java and java17 JeanneTest.java to easily compare differences.

alias javac17=/Library/Java/JavaVirtualMachines/jdk-17-ea.jdk/Contents/Home/bin/javac
alias java17=/Library/Java/JavaVirtualMachines/jdk-17-ea.jdk/Contents/Home/bin/java
alias jar17=/Library/Java/JavaVirtualMachines/jdk-17-ea.jdk/Contents/Home/bin/jar
alias javac11=/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home/bin/javac
alias java11=/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home/bin/java
alias jar11=/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home/bin/jar
alias jshell11=/Library/Java/JavaVirtualMachines/jdk-11.0..jdk/Contents/Home/bin/jshell
alias jdeps11=/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home/bin/jdeps
alias jmod11=/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home/bin/jmod

export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk-17-ea.jdk/Contents/Home"