A JVM written in go. [0] We're committed to a high-quality implementation that works reliably--so our test code is > 2.x the size of our production code. We can already run lots of classes, but the finished product won't be ready for alpha testing until, we hope!, end of this year.
Here's the text I believe that you're looking for:
> I've always thought of the JVM as magical technlogy--I'm certainly not alone in that view. But in trying to learn more about it, I was greatly frustrated by the difficulty of reading the code base.
As you likely know, the Hotspot JVM is open source. But reading the code is very difficult, in part because it grew organically and in part because of its unusual design, in which many actions are buried deep at the end of a long series of function calls involving unexpected classes and unusual methods, etc.
> This led me to thinking there would be value in a JVM written as a single cohesive codebase. And given that there is a 300+ page JVM specification and a reference implementation, I thought to myself, how long could this take? Two years later, and with help from two major contributors, we're still finding out! ;-)
> Eventually, we hope, it will be a fun/interesting experience for users to pop open their Go IDE and watch a Java program execute--which is why we're intent on making sure it's written in 100% go.
> In a larger context, Jacobin might eventually be useful as an embeddable JVM.
Thanks for your note. The package notes on Jacobin say that we strongly discourage folks from running it in its present form. There are enough features still to be implemented, that for anything but trivial classes, you won't have a good experience. TBH, we're about a year out (we think) from having a version we can solicit users to test.
Nonetheless, if you'd be kind enough to post the above error and the class you used into the GitHub Issues tracker [0], we'll definitely include it in our test suite and make sure whatever the problem is, it'll be corrected.
Author here. Zero-length arrays are used in the narrow ___domain you mention. but they are rare in bread-and-butter Java programming. Given some of the other comments on this page, you can see that this aspect is new to multiple readers. And in my experience speaking to Java devs, the reaction of surprise is far more common than "of course, I use them."
Thing is, practically every modern programming language has zero-length arrays or lists. This is derived from Lisp, which had zero-length arrays (and of course zero-length lists). It's not at all surprising. What ought to be surprising is that among languages developed in the last 40 years, C++ almost uniquely does not have them. I use zero-length arrays all the time in my coding, as does everyone I know. I think they're probably much more common than you imagine.
Author here. Thanks for your comment. It's sometimes a little difficult to know how deeply to go into the innards of the JVM before readers' eyes glaze over and they can't follow. I'll bear in mind for future articles in this series that I can/should go deeper than the present level.
Author here. This is simply a comment on the way that Java refers to the subarrays. I believe most developers would think of the first subarray as being referenced with [0], rather than with no index at all. That's all the comment was intended to point out.
Author here. Your "correction" is wrong. All dimensions after the zero dimension are ignored by the JVM. This is explicitly stated in the JVM spec[0].The typecheck you're leaning on is a purely syntactical construct. Inside the JVM, the arrays function and are sized just as I described.
> Object having no size() method and arrays having therefore a length field is also confused. Arrays have distinct types (and classes, in the sense of getClass()), and therefore could very well have a size() method. It’s merely a stylistic choice of Java that they opted for the simpler .length syntax.
What's the "confused" part? Again, my description is accurate and you're simply saying that Java could have chosen a different way to do the same thing, but decided not to.
> All dimensions after the zero dimension are ignored by the JVM. This is explicitly stated in the JVM spec[0].
What is stated is: “If any count value is zero, no subsequent dimensions are allocated.” This is mostly just for clarification, because what could the alternative possibly be? It is equivalent to saying that count subarrays are allocated, which when count is zero, of course means that none are allocated. Again, what would the alternative possibly be?
Furthermore, strangePoints.getClass() results in `[[[[I` (so it’s not just syntactical, it’s the actual runtime type), i.e. a four-dimensional array of ints, and not a two-dimensional array of ints as the article claims.
What is true is that what is allocated is a two-dimensional array, but it is an array of empty arrays, not of ints. For example, the expression strangePoints[0][0].length is valid (and yields 0), whereas it wouldn’t be valid for a two-dimensional array of ints. And again that’s on the JVM level, because otherwise the ARRAYLENGTH operation wouldn’t work here. Furthermore, strangePoints[0][0].getClass() of course is valid as well and yields `[[I`, showing that the element type of the two-dimensional array is another two-dimensional array (of ints), and not int.
> What's the "confused" part?
The confused part is this: “Many Java collections have a method called size(), which returns an integer stating the number of elements in the collection. Arrays have no such method. There are several reasons for this, but the principal one is that arrays are simple Object instances—they are not collections. The Object class has no size() method, so arrays don’t either.”
There is no reason why array objects couldn’t have a size() method even though Object doesn’t. Invoking getClass() on an array doesn’t return Object.class, but a subclass of that, and those subclasses could have the additional size() method.
This is also wrong: “Eagle-eyed readers of my earlier statement about length being a field rather than a method call might wonder how a direct subclass of Object would have a field called length to begin with, as Object has no such field.” Arrays don’t have a length field, as calling .getClass().getFields() (or getDeclaredFields()) on an array shows. The .length property is mere syntax, much like .class on an object type. But, again, Java/the JVM could have chosen to imbue array classes with a fully-fledged size() method.
> What is stated is: “If any count value is zero, no subsequent dimensions are allocated.” This is mostly just for clarification, because what could the alternative possibly be?
The key part comes a bit later:
> The components of the last !!allocated!! dimension of the array are initialized to the default initial value (§2.3, §2.4) for the element type of the array type.
Since the last allocated dimension is the one that has zero count... well, that means each component (of which there are none) is initialized to a value of type `int`, so technically speaking, the type of each component (of which there are none) is `int`. Due to the rest of the spec, that means the type of the dimension before that is `int[]`; and that's how you arrive at the conclusion of TFA.
It's quirky, and a semantic argument at best, and certainly not worth fighting over here on HN.
Lead dev here. Yup, that's right. There are a few classes that we will be forced to implement in Go. We're fixated on keeping this number as low as possible, but Thread is one that is inescapable. Class is another inescapable one--if we're to support reflection, etc.
[0] jacobin.org