Speaking at JavaOne!

This year was my first visit to JavaOne and I got to go as a speaker! This wasn’t my first year applying, but it was my first year being accepted. If you are looking for my live blog posts, see the table of contents.


In addition to the usual (summary/abstract and bio), you had to submit a description of the session. You also had to submit a video of you speaking. I used the Mutation Testing talk from the NY Java User Group.

Getting accepted

On July 28th, I got an email saying my “JUnit 5 Hands On Lab” was accepted and I had two weeks to accept/decline. (I know people who got accepted two weeks earlier so I had originally thought I was rejected rather than being in “Phase 2.”) Then in later August, I got accepted for my “Intro to Mutation Testing” talk. This was about 5 weeks before the conference; luckily the mutation testing talk already existed and just needed minor edits/review. The on August 25th, I got the date/time of my sessions. Here’s my two sessions!

Picking Sessions

Before the conference, you have the opportunity to pre-register for sessions. Some fill up; especially hands on labs. If you don’t pre-register for a session, you can still try to attend off a physical wait list. But you get in earlier (and guaranteed) if you sign up. If a session got cancelled or changed rooms after pre-registering, you also got an email.

Getting Ready

I had done the mutation testing session before (well a shorter version of it). The JUnit 5 lab was new. It was fun to write. Like writing a chapter in a book (see it in github). But easier because I’d get to meet my audience. Steve Moyer from Penn State University and his two teammates offered to help me proctor the lab. This was immensely helpful. I practice both sessions a few times. Then I was ready!

There was some confusion about the Hands On Lab. Originally we were told that all labs would use VMs. After setting up my VM and submitting it, they said JavaOne sessions would use attendee laptop. Oh well, at least I got to play with Windows 10.

At the event

I got there and saw Duke inviting us in. Well, a cardboard Duke!

I also saw the JavaOne bookstore and took pictures with Scott and my books. I even went back later to see them with less books there.

Oh, and outside the conference, I rode a Segway. First time on a city street.

During a JUnit 5 session, Steve Moyer plugged my session:

And then there were my sessions:










After hours, I was on the winning team at IBM’s escape room with Sai (from the NY Java Sig) and three people we just met from Canada.

And of course I got to give Duke a hug!

After the conference
Shortly after each session, you could see the number of people who came to your session. I was at room capacity (or one under) for both sessions. I had a physical wait list line for both. For the JUnit 5 lab, someone even got on line 30 minutes early to ensure he’d get in!

In about a month, we get feedback from attendee surveys. Neither of my rooms was in a room with a thumbs up/side/down button so I’ll only get feedback from those who filled out the survey online. I got good feedback out loud though!

JavaOne – How to Make a Project Java 9 Compatible

“How to Make a Project Java 9 Compatible”

Speaker: Nikhil Nanivadekar

For more blog posts from JavaOne, see the table of contents

Examples use Eclipse Collections

Examples from:


  • Used ArrayListAdapter which uses reflection
  • Got illegal-access warning (when default was warn; now it is permit
  • If run with illegal-access=deny, it fails
  • Lesson: have lots of regression tests so know about such errors
  • Lesson: Allow a lot of time to migrate. Don’t start Friday evening. Long sequence of “just one more compilation error to fix”

Infering types

  • Compler error because can’t assume generictype to return
  • Comes up when class doesn’t have a generic type and try to store it in one that does.
  • Compiler not supposed to infer type
  • Fix is to cast or store in a local variable
  • Similarly need to declare types on class instatiation if not diamond operator usage


  • collect() now calls Objects.requireNotNull(combiner).
  • In Java 8, a null combiner worked in serial mode because not used.

“I love compiler errors vs runtime exceptions”

Migrating a Java 8 Maven project to Java 9

  • Migrated a maze solving project. Was written recently so not legacy code
  • Switch source/target of maven-compiler-plugin to “9”.
  • Changed JDK in IntelliJ.
  • Maven itself works fine with Java 9. Compiling works. JavaDoc and Enforcer plugins work fine with milestone version; not yet for released versions. Seewiki on support for Java 9 in Maven plugins
  • Looking at modularizing library in future
  • Runs without adding module info file or doing anything else
  • Once add module file, more enforcement happens. ex: error on unnamed packages
  • Eclipse and IntelliJ have quick tip to add requires
  • Important: start with base module
  • If not using a build tool, need to ensure no cyclic dependencies. (build tool takes care of this for you)
  • Add exports clause for module. The compiler error just says the class isn’t found. It doesn’t say it is because the export is missing.
  • Move code in split package to another package updating all callers
  • Delete empty package; can’t have empty package
  • Hide internal packages by not exporting sub-packages

My take: Nice to see issues by example. And nice to see that it wasn’t “all about Jigsaw.” It was a good mix of problem types!

JavaOne – Optional – the mother of all bikesheds

“Optional – the mother of all bikesheds”

Speaker: Stuart Marks

The deck is available online

For more blog posts from JavaOne, see the table of contents

Showed early version of “optional” (stream returning null)

Review of basics

  • Two states – present (contains non null reference) or absent
  • Don’t say “null optional”. Say “absent” or “empty”
  • Optionals are immutable
  • equals() and hashCode() work as one would expect – useful for JUnit because can call assertEquals()

New in Java 9

  • stream() – stream with 0 or 1 elements
  • ifPresentOrElse(Consumer)
  • or(Supplier)

Good code and Best practices

  • Never set an Optional variable to null. It should be Optional.empty() as default.
  • If method returns Optional, never return a null either.
  • Intended for return types where might or might not have a value to return.
  • Don’t call get() as could be empty optional
  • Use isPresent() and get() as last resort
  • Using .map().orElse() chained after stream pipeline gives fluent API calls
  • Calling filter() returns original value only if non-empty optional that matches. else returns empty. Using filter() and orElseThrow() is good for validation
  • [and more see the deck]

My take: Amazed there is so much to say about Optional! Excellent set of best practices. And excellent point on not calling an optional “null.” I needed to leave early as my session is immediately after this one. And I really wanted to know “what’s with the bikeshed” which is covered last.  It’s a nice collection of quotes. So I found the deck and best practices online. There’s also a youtube video linked so you can watch at home.