JVM: The Constant Pool
It’s snowy, windy and dark outside. It is a perfect weather to read a technical spec, isn’t it?
Let’s read about a .classfile’s constant pool today.
It’s snowy, windy and dark outside. It is a perfect weather to read a technical spec, isn’t it?
Let’s read about a .classfile’s constant pool today.
This post is a note taken during reading 4.2 and 4.3 sections of chapter 4.
Section 4.2 describes the rules of representing class and interface names, field and method names, module and package names.
Section 4.3 describes descriptors and provides a short grammar according to which a representation of a type is constructed.
CONSTANT_Utf8_info structuresCONSTANT_NameAndType_info and from CONSTANT_Class_info structuresUnqualified names are used to strore:
Each .class file contains the definition of a single:
Class format (the specific order and meaning of bytes) described in the spec not neceserily applies to an actual file on the filesystem: those “bytes” might have been read from the database, downloaded from the web or constructed by a class loader; keep this in mind whenever you encounter the phrase “class file format”.
Here’s a short overview of the instruction set for the JVM.
Chapter 2 reading notes: types and runtime data areas, and a bit about threads. Opcodes will come soon 😄! Source: chapter 2 of JVM specification.
Let’s start small: start by reading the specification’s introduction
While playing with p5.js I often stumble upon a problem of color palette choice. The colors that I use in my artictic/programming playground are (usually) randomly generated. Even though I’m familiar with practical superiority of HSL/HSB over RGB colorscpace and I seldom use RGB in my scripts, I haven’t tried to create a color palette algorithm myself.
I’m sure there are many such algorithms. There are plenty of pages that allow the user to enter a color and they helpfully output a set of matching, somehow related colors that form some kind of a palette. The obvious target users of such pages are: