I think the answer you need starts with this comment you yourself made in reply another answer:
The pattern is a result of the interplay of Java, the JVM, the OS, the CPU + caches, the hard disk, the Trance music I was streaming that consumes CPU /RAM cycles and everything in between. The pattern simply arises from the one line of Java code inside a for/next loop. A significant part of the entropy comes from the underlying hardware circuits.
You already realize this, I think: you didn't use deterministic means to create the pattern.
You used a computer, a non-negligible part of which is deterministic, but the entropy came from external non-deterministic (or at least, non-deterministic for all practical intents and purposes at the moment) sources: you or the external world interacting with the computer (and to a lesser extent, any physical imperfections in the computer hardware that might effect the timings of things).
This, by the way, is a big part of how modern operating systems seed their random number generators that are available to programs: by harnessing the entropy in interactions with its hardware and the user that we hope are not predictable to an attacker.
By the way, external-world entropy is actually a problem that has to be dealt with to this day in otherwise well-coded cryptography: computers that have predictable behavior upon boot and during their runtime, such as those with read-only storage or which boot from the network, and which have a predictable network environment (either not attached to a network or the workload on the network is low enough that everything is delivered within a reliable amount of time), and which run the same limited set of software with roughly consistent behavior, might grossly over-estimate the entropy they are getting from these assumed-to-be-unpredictable components, and end up generating far more predictable numbers than you'd get on a typical work-station that's doing all sorts of other stuff for you (streaming music, syncing with dropbox, whatever) in the background.
I think most answers are getting focused on whether checking the last eight bits of time measurements in nanoseconds taken in a loop is a good way to harvest that entropy. This is a very important question to properly answer before you use the method in your example as a random number generation scheme in practice, but it's a separate question from what I think you are asking about. 77