This post starts Java 8 refresher series - I will keep here my short notes during reading “Modern Java in Action”.

I would like to keep my secrets in encrypted directory. It seems that there already exists a nice solution to this problem and it is called encfs.

For reference, I found online manual with examples after visiting baeldung linux article first.

So, let’s do it.

Create a pair of directories

Here I’m creating two directories:

• ~/.crypt is the source directory - here encrypted data are stored
• ~/crypt directory which is the mountpoint - here I would see decrypted files to work with

1

[karma@tpd] mkdir ~/crypt ~/.crypt

Create encfs

Now, in order to start working with encsfs I issue following command: encfs source mountpoint:

It’s snowy and rainy, although it is April already according to the calendar. A few days ago I’ve seen little yellow flowers growing in the snow (snowdrops and aconite). It’s also very windy today (I can hear howling in ventilation chimneys) and it was raining all night long.

I need some more colors to dissipate the unpeasant aura. I’ve decided to write a small graphics generator for easter eggs.

The code is available at GitLab, in snowflake project and the generator itself is available on kamilachyla.gitlab.io page.

This chapter of JVM Specification describes three phases of life of a JVM class: loading, linking and initializing.

In order to start executing main method (public void main(String[] args)) of the main (or: initial) class the JVM needs to have a runtime representation of the class. If JVM does not have it, it needs to construct it from binary representation. This is called loading.

The weather is still “very february”, so I grab a cup coffee ☕, start reading and taking notes.

This post completes Chapter 4 of the JVM Specification - it quickly goes through format checking, shows two types of Code attribute checks and lists JVM limitations.

Format Checking

Before the class is loaded, JVM needs to ensure that the .class file has appropriate format. There are five basic integrity checks that are performed on a .class file:

Attributes in the .class file layout

In previous post I made some notes about constant_pool. Looking at the order in which data is layed out in the class file, constant_pool is followed by some general information specific to the class like its name, names of implemented interfaces or its superclass (see the post JVM: Class file structure). Information about fields and methods comes next.

Both fields as well as methods are represented with the same general structure:

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.

Names

Binary class and interface names

• those names always appear in a fully qualified form known as binary name (see JLS 13.1)
• they are represented with forward slash instead of a dot (for historical reasons)
• represented as CONSTANT_Utf8_info structures
• referenced from CONSTANT_NameAndType_info and from CONSTANT_Class_info structures

Field and method names

Unqualified names are used to strore: