In an earlier post, I described how to install the latest version of the Oracle Java JDK using homebrew. What hadn't been completely obvious to me when I wrote the original blog post is that the 'java' cask will install the latest major version of the JDK. As a result, when I upgraded my JDK install today, I ended up with an upgrade from Java 8 to Java 9. On my personal machine that's not a problem, but what if I wanted to stick with a specific major version of Java?
Emacs 25.3 has been released on Monday. Given that it's a security fix I'm downloading the source as I write this. If you're using the latest Emacs I'd recommend you update your Emacs. The vulnerability as been around since Emacs 19.29, you probably want to upgrade anyway.
I've been experimenting with converting this blog to Jekyll or another static blog generator. I'm sticking with Jekyll at the moment due to its ease of use and its plugin environment. The main idea behind this is to reduce the resource consumption and hopefully also speed up the delivery of the blog. In fact, there is a static version of the blog available right now, even though it's kinda pre-alpha and not always up to date. The Jekyll version also doesn't have the comments set up yet nor does it have a theme I like, so it's still very much work in slow progress.
I haven't used Ubuntu much recently after switching several systems to Manjaro, but had to set up a laptop with XUbuntu 17.04. That came with Emacs 24.5 as the default emacs package, and as skeeto pointed out in the comments, with a separate emacs25 package for Emacs 25.1. I tend to run the latest release Emacs everywhere out of habit, so I revisited my build instructions to build a current Emacs on Ubuntu and its derivates. The good news is that in thanks to some changes in the Emacs build, the build is as straightforward as it used to be prior to the combination of Ubuntu 16.10 and Emacs 25.1. In other words, no need to remember to switch off PIE as was necessary when building GNU Emacs 25.1 on Ubuntu 16.10.
This is a post I wrote several years ago and it's been languishing in my drafts folder ever since. I'm not working on this particular codebase any more. That said, the problems caused by using Java-like getter and setter functions as the sole interface to the object in the context described in the post have a bigger impact these days as they will also affect move construction and move assignment. While I'm not opposed to using getter and setter functions in C++ in general, I am opposed to using them as the only member access method and especially in this particular context where they had to be used to initialise class members that were complex objects themselves.