GitHub project: mikenakis-rumination

Making plain old java objects aware of their own mutations.

The mikenakis-rumination logo.
Based on original from free-illustrations.gatag.net
Used under CC BY License.


GitHub project: mikenakis-testana

A command-line utility for running only those tests that actually need to run.

The mikenakis-testana logo, profile of a crash test dummy by Mike Nakis
Used under CC BY License.


GitHub project: mikenakis-classdump

A command-line utility for dumping the contents of class files.

The mikenakis-classdump logo.
Based on an image found on the interwebz.


GitHub project: mikenakis-bytecode

A lightweight framework for manipulating JVM bytecode.

The mikenakis-bytecode Logo, an old-fashioned coffee grinder.
by Mike Nakis, based on original work by Gregory Sujkowski from the Noun Project.
Used under CC BY License.


On Coding Style

Since I have a few projects on GitHub, I suppose a word or two are in order, on the subject of coding style.

When I write code within a team of developers, I use the team's coding style.

However, when I write code for myself, I use my very own™ coding style.

In my career I have experimented a lot with coding styles, mostly while working on pet projects at home, but also in workplaces where each developer was free to code in whatever way they pleased, or in workplaces where I was the only developer.

My experimentation has been in the direction of achieving maximum objective clarity and readability, disregarding convention, custom, precedent, and the shock factor: the fact that a particular style element might be alien to most developers out there plays little role in evaluating the objective merit of the element.

So, over the years I have tried many things, once even radically changing my coding style in the middle of a project. (Modern IDEs make it very easy to do so.)  Some of the things I tried I later abandoned, others I permanently adopted.

So, my coding style today is the result of all this experimentation. If it looks strange to you, keep in mind that every single aspect of it has been deliberately chosen to be this way by someone who was not always coding like that, and who one day decided to start coding like that in the firm belief that this way is objectively better. 

In moving on with each of these changes over the years, I had to overcome my own subjective distaste of the unfamiliar, for the benefit of what I considered to be objectively better. 

So, if you decide to judge my coding style, please first ask yourself to what extent you are willing to overcome the same.


GitHub project: mikenakis-agentclaire

A Java Agent to end all Java Agents.

The mikenakis-agentclaire logo
based on a piece of clip art found on the interwebz.


Open Source but No License

I have posted some small projects of mine on GitHub, mainly so that prospective employers can appreciate my skills. I am not quite ready to truly open source them, so I published them under "No License".  This means that I remain the exclusive copyright holder of these creative works, and nobody else can use, copy, distribute, or modify them in any way, shape or form. More information here: choosealicense.com - "No License" (https://choosealicense.com/no-permission/).

Pretty much the only thing one can legally do with these creative works is view their source code and admire it.

GitHub says that one can also make a copy of my projects, (called fork in GitHub parlance,) but I am not sure what one would gain from doing that, because you cannot legally do anything with the forked code other than view it and admire it.  Even more information here: Open Source SE - GitHub's “forking right” and “All rights reserved” projects (https://opensource.stackexchange.com/q/1154/10201)

(Okay, if you compile any of my projects and run it once or twice in order to check it out, I promise I will turn a blind eye.)

If you want to do anything more with any of these projects, please contact me.


On JUnit's random order of test method execution

This is a rant about JUnit, or more precisely, a rant about JUnit's inability to execute test methods in natural method order. (The order in which they appear in the java source file.)

Note: I have not tried JUnit 5 yet, so some or all of this may be inapplicable today.

Up until and including Java 6, when enumerating the methods of a java class, the JVM would yield them in natural order, as it should. However, when Java 7 came out, Oracle changed something in the way classes are loaded, and so this operation started yielding methods in a seemingly random order. (Hash order probably, which is effectively random.)

Apparently JUnit was executing methods in the order in which the JVM was yielding them, so as a result of upgrading to Java 7, everybody's tests started running in random order. This caused considerable ruffling of feathers all over the world. 

People asked the creators of JUnit to provide a solution to this, but nothing was being done for a long time, allegedly because if You Do Unit Testing Properly™, you should not need to run your tests in any particular order, since there should be no dependencies among them. So, apparently, according to the creators of JUnit, if you want your tests to run in a particular order, it must be because you have tests that depend on other tests.

When the creators of JUnit finally did something to address the issue, (it did not take them long, only, oh, until Java 8 came out,) their solution was completely half-baked: the default mode of operation was still random method order, but with the introduction of a special annotation one could coerce JUnit to run test methods either in alphabetic order, (which is useless,) or in some other weird, ill-defined, so-called "fixed" order, which is not alphabetic, nor is it the natural order, but according to the JUnit documentation it guarantees that the methods will be executed in the same order from test run to test run. (And is also completely useless.) 

So, apparently, the creators of JUnit were willing to do anything except the right thing.