Java on Code Log

The Implementation Details of hashCode()

Sun, 13 Sep 2015 22:32:31 +0800

Image source:Wikipedia

The Real Value of an int Variable Starting with 0 in Java

Tue, 10 Mar 2015 17:54:32 +0800

Today, while solving a problem on LeetCode, I accidentally discovered the following issue:

What value does the following Java statement output?

System.out.println(00123);
System.out.println(0_123);

The answer is:

83
83

Understanding the Java String.intern() Memory Model

Tue, 20 Jan 2015 14:05:51 +0800

As you know, calling string.intern() in Java first looks up the corresponding string in the string constant pool; if the string does not exist, it is created in the pool and then returned.

The string constant pool is a fixed-size HashMap whose default bucket count is 1009; starting from Java 7u40, this default was increased to 60013. In Java 6, the string constant pool was located in the Perm space, and starting from Java 7 it was moved to the Heap space. Below, we use a test program to look at the memory allocation of the string constant pool under the two different versions, Java 6 and Java 7.

JBoss AS7 Class Loading Mechanism

Thu, 15 Jan 2015 11:05:51 +0800

Compared to earlier JBoss versions, AS7’s class loading mechanism is entirely different. AS7’s class loading is designed around JBoss modules. For an introduction to JBoss modules, see the previous article JBoss Module Introduction.

Implicit module dependencies

When you deploy an application to a JBoss container, some dependencies are loaded implicitly. For example, if you deploy a Java EE application that contains EJBs, since EJBs need the Javax.ejb.* package and other Java EE API related packages, the JARs containing those packages are already packaged into modules and included in the container by default as part of JBoss AS, so the modules for those JARs are loaded automatically.

So when are implicit module dependencies loaded? When an application is deployed to the container, it passes through a chain called the “deployment processors”. Each processor on this chain has a method to detect whether the application needs certain modules to be loaded implicitly, and if so, loads the relevant dependencies.

JBoss AS7 Module Introduction

Tue, 13 Jan 2015 16:27:00 +0800

Compared to earlier JBoss versions, AS7’s class loading mechanism is entirely different. AS7’s class loading is designed around JBoss modules.

What is a module

A module is a collection of classes and resources, and each module corresponds to a class loader. Modules can have dependencies on one another: if a JAR in one module needs to use classes from a JAR in another module, the dependency must be declared explicitly; otherwise the modules are invisible to each other. Likewise, if you deploy an application to a JBoss AS7 container and the application depends on modules, those dependencies must also be declared explicitly.

If you want to understand the JBoss AS7 module loading mechanism in depth, see: JBoss Module Analysis

Benefits of modules

JARs of the same version are not loaded repeatedly.
Avoids JAR version conflicts.
Provides a more efficient class loading mechanism.