I've been anxiously awaiting the 3.0.0 release of the
maven-javadoc-plugin
for weeks, and in an ironic twist of fate, I'm now responsible for delaying
the release even further.
I found two rather nasty bugs in the version
that was to become 3.0.0, but submitted a
fix
for the first and had it merged. The second problem
seems like it's going to take rather more work to fix
though, and my message asking for implementation advice to the
javadoc-dev
list is currently sitting in a moderation queue.

What to save and throw away?
pr?The last hour is on us both?mr.s?tuck this little kitty into the impenetrable brainpan?
pr?Contents under pressure?Do not expose to excessive heat, vacuum, blunt trauma, immersion in liquids, disintegration, reintegration, hypersleep, humiliation, sorrow or harsh language?
pr?When the time comes, whose life will flash before yours?
pr?A billion paths are here inside me? pr?yes, yes, yes, Bernhard, 110? pr?potential, jewels, jewels, yes, jewels? %
Decided to kill off some old
packages. jnull and
jfunctional in particular
I've used in just about every project I've ever worked on. There's
really very little reason for them to exist anymore though. Java
8 added Objects.requireNotNull which standardized terse null
checking. Noone cares about the @NonNull annotations (including
myself). The entire contents of jfunctional were made redundant
by Java 8. Both of these packages served their purposes well back
in the days of Java 6 when they were first designed, but now they're
just a burden.
It's good to throw away code.
I'm still waiting on a set of issues to be resolved in order to push modules to all of my projects.
MJAVADOC-489 causes JavaDoc generation to fail when one module requires another.
MDEP-559 causes
the dependency:analyze goal to fail. I use this goal
as part of all my builds in order to keep dependencies
clean and correct. Getting this fixed depends on
MSHARED-660.
I've also removed japicmp from
all of my builds. I don't want to disparage the project at all;
it's good at what it does, but using it would require using custom
MAVEN_OPTS on JDK 9, and that's just not good enough. I'm in the
process of writing a replacement for japicmp and will announce it
within the next few weeks.
Instead of using a non-default MTU on my network, I've instead implemented TCP MSS clamping.
Specifically, I reset all of the interfaces on my networks back to
using an MTU of 1500 (including those on the router), and added
the following pf rule:
scrub on $nic_ppp max-mss 1440
That rule clamps the maximum TCP segment length on the
PPP interface to 1440. Why 1440? It's
essentially down to the per-packet overhead of each protocol that's
involved. Typically, that'll be 40 or so bytes for an IPv6 packet
header, 8 bytes for PPPoE, and some
loose change.
So far, nothing has broken with the new settings. No TLS handshake failures, no sudden broken pipes on SSH sessions, no issues sending mail.