Class Library Integration

Class Library Integration

Integration mechanisms connecting GNU Classpath and OpenJDK with JNode's VM, classloader, and Java API extensions.

Overview

Class Library Integration is the architectural layer that enables JNode to run standard Java applications by bridging the gap between standard Java class libraries (GNU Classpath and OpenJDK) and JNode's custom JVM implementation. Unlike hosted Java environments that rely on the underlying operating system for native method implementations, JNode must provide all native functionality directly through VM-specific implementations.

The integration operates across three bridge areas: the JVM (native method implementations), the classloader (class loading and resolution), and the Java API (extensions beyond standard classes). This allows JNode to maintain Java API compatibility while adding OS-specific capabilities.

Key Components

Class / File	Role
core/src/classpath/vm/	VM-specific implementations of GNU Classpath VM classes
core/src/classpath/ext/	JNode extensions to standard GNU Classpath classes
core/src/openjdk/vm/	VM-specific implementations of OpenJDK VM classes
all/lib/classlib.jar	Downloaded base class library from build system
org/jnode/vm/classmgr/	Class loading and type management

How It Works

Integration Architecture

The class library integration works through a layered approach:

[Standard Java Classes] → [JNode VM Overrides] → [JNode VM Core]
       (classlib.jar)        (vm/ packages)       (core/)

1. Base Library Loading: During build, the system downloads standard GNU Classpath and/or OpenJDK jars to all/lib/classlib.jar.

2. VM Override Resolution: When the BootImageBuilder creates the boot image, classes in core/src/classpath/vm/ and core/src/openjdk/vm/ replace standard implementations. For example, gnu.classpath.SystemProperties is replaced by JNode's NativeSystemProperties.

3. Native Method Binding: Standard Java classes that declare native methods are bound to JNode's VM implementations rather than host OS calls. This uses @MagicPermission annotations and VmMagic to access VM internals without JNI.

JVM Bridge

The JVM bridge provides native method implementations that interface directly with JNode's kernel:

• Thread Management: VMThread implementation connects to JNode's scheduler
• System Properties: SystemProperties hooks into JNode's configuration
• I/O Primitives: File and network operations use JNode's native drivers
• Reflection: Stack walking and class introspection use VM internals

Classloader Bridge

The classloader bridge manages how classes are loaded and resolved:

• Classes from classlib.jar are resolved first
• JNode's VM implementations take precedence over standard implementations
• Custom classloaders can intercept and modify the loading process

Java API Extension

Beyond compatibility, JNode extends the standard Java API:

• JNode-Specific Packages: org.jnode.* packages provide OS features
• Extended Classes: javax.jnode.* adds capabilities not in standard Java
• Security: JNode's security manager integrates with the VM

Gotchas & Non-Obvious Behavior

• No JNI: Standard JNI is not available. All "native" methods must have JNode-specific implementations.
• Boot Image Order: Class resolution order matters - JNode VM classes must be resolved before standard classes in the boot image.
• Package Visibility: Some JNode VM classes are in gnu.classpath or sun.* packages to maintain compatibility with code that expects those namespaces.
• Patch Markers: Look for comments like // @classpath-bugfix in source to identify JNode-specific fixes.

Related Pages

• Class-Library - Basic class library documentation
• VM-Magic - Magic annotations for VM integration
• Build-System - Build process and classlib.jar management
• Architecture - System architecture overview
• Type-System-Internals - Class loading and type management