Category: Tech Notes

Posted on

Installing OpenJDK 11 on MacOS

If you download the .tar.gz for OpenJDK 11 direct from http://jdk.java.net/11/, there’s no obvious install instructions (at least that I can find) either on the OpenJDK website on in the .gz file. If you’ve done any fiddling with different JDK versions on MacOS before, you’ve probably come across the ‘/usr/libexec/java_home’ utility (see here for my previous article about this utility, and answers to this StackOverflow post which includes one of the most extensive and useful guides to running different JDK versions on MacOS that I’ve seen) which does a number of useful things relating to which JDK you’re currently using in your PATH:

/usr/libexec/java_home : shows you were the current JDK home is, eg:

/Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home

/usr/libexec/java_home -V : lists all installed JDKs, e.g.:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
    10, x86_64:    "Java SE 10"    /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home
    1.8.0_151, x86_64:    "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home

To switch between JDKs, use /usr/libexec/java_home -v version (e.g. 10):

$ /usr/libexec/java_home -v 1.8.0_151
/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home

Knowing that your available JDKs are installed to /Library/Java/JavaVirtualMachines/ by default, moving the contents of the downloaded OpenJDK 11 dir from inside the .gz file to the same location would make sense.

Once you’ve moved it there, java_home -V now shows the new JDK in place:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (3):
    11, x86_64:    "OpenJDK 11"    /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home
    10, x86_64:    "Java SE 10"    /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home
    1.8.0_151, x86_64:    "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home

Updating my aliases to quickly switch versions in my .bash_profile, I now have:

alias j11="export JAVA_HOME='/usr/libexec/java_home -v 11'; java -version"
alias j10="export JAVA_HOME=`/usr/libexec/java_home -v 10`; java -version"
alias j8="export JAVA_HOME=`/usr/libexec/java_home -v 1.8`; java -version"

Sourcing the .bash_profile (source .bash_profile) and then running each alias, now I’ve got OpenJDK 11 set up and ready to go!

$ j11
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
Posted on

My HDDs with most uptime hours

I keep a few old HDDs around as scratch disks for installing random stuff. I realized a couple of them I’ve been using fairly regularly in my Mac Pro are pretty old, so took at look at the SMART stats (smartctl) to see how old they actually are, and what their stats and uptime actually are:

WD Caviar Blue 500GB – this drive came installed in my 2008 Mac Pro when I bought it used. I’ve no idea if it was an original disk in the machine or added later, but it’s still chugging along with no errors and over 3.7 years uptime:

32,830 uptime hours
0 read error rate
SMART health: PASSED

Hitachi Deskstar 3.5″ 7200rpm P7K500 250GB – I have 2 of these disks that I used in a Linux server as a RAID1 pair when I used to self host my website from home. Still no errors and over 5 years uptime so far:  

45,082 uptime hours
0 read error rate
SMART health: PASSED

I understand that both of these are on borrowed time and I don’t use these for anything critical, but it’s interesting to see how long some disks last. On the other end of the spectrum I’ve also had several disks fail within a year, and one (a Quantum Fireball I think) failed within a couple of weeks, but it’s interesting to compare the lifetimes and failures from a number of disks over time.

Posted on

WordPress error uploading photos on nginx: “client intended to send too large body”

Attempting to upload some new photos between around 3 to 5MB, the majority of the uploads failed, and this error was occurring repeatedly in my nginx error.log:

2018/08/06 07:18:37 [error] 43#0: *5 client intended to send too large body: 3125530 bytes

Based on this tip from here, the solution was to increase the default POST body size config with this setting in my nginx.conf:

client_max_body_size 5M;
Proudly powered by WordPress