Topic 9 of 119 1. Introduction to Java Interactive Tutorial

How Java Achieves Platform Independence

14 mins read Last updated: 22 Aug 2026 16,557 views

Java Code Editor DOCX (119 Topics) 0.00%

On This Page0 sectionsQuick jump to subtopic

Direct Answer & Core Concept

Java delivers WORA through **two** mechanisms, and it is worth separating them because they have different limits. First, `javac` compiles source into **platform-neutral bytecode** in a `.class` file. I inspected the raw bytes and found the magic `ca fe ba be`, major version 61, and **no operating-system strings whatsoever** — no path separators, no platform name, no native handles. That neutrality is backed by fixed-width language guarantees: `int` is always 4 bytes, `long` 8, `char` an unsigned 16-bit UTF-16 unit, and `float`/`double` strictly IEEE 754, with all floating-point expressions strict by default since JEP 306 in JDK 17. Second, each platform ships its **own native JVM** that executes that bytecode: `libjvm.so` on Linux (ELF, verified here), `libjvm.dylib` on macOS, `jvm.dll` on Windows. The JVM is not merely an interpreter; HotSpot JITs to native code within milliseconds of startup, confirmed with `-XX:+PrintCompilation`. **Android is the notable exception**, running ART on DEX bytecode via an extra `d8` conversion step rather than executing class files. Where WORA genuinely fails is behaviour rather than execution. The clearest demonstration: identical bytecode on one machine returns `TITLE` under an English locale and `TİTLE` under `tr-TR`, because no-argument `toUpperCase()` consults the default locale and Turkish has a dotless I. Similarly `"a".compareTo("B")` returns **31**, a raw code-unit comparison, so human ordering requires the locale-dependent `Collator`. Default charset is also environment-dependent: JEP 400 made UTF-8 the default from **JDK 18**, whereas earlier releases followed the platform locale, typically windows-1252 on Windows. Path separators, case sensitivity (Linux is case-sensitive, Windows usually is not), and JNI native libraries vary too. Finally, portability is **one-directional**: I confirmed a `--release 8` class (major 52) runs fine on JDK 17, while major 61 bytecode on a Java 8 JVM fails with `UnsupportedClassVersionError`. The precise formulation is that your *bytecode* is portable, but your *behaviour* is not automatically correct on every platform.

Detailed Explanation & Mechanics

1. What WORA Actually Claims, and Where It Breaks

The "Write Once, Run Anywhere" slogan describes a real mechanism, and it is genuinely load-bearing. But it is an idealisation, and understanding it properly means knowing three things: what it gets right, what it does not, and which specific operations betray it.

The original version of this topic listed three mechanisms. **Two of the three were correct. One was substantially wrong**, and the most useful part of this article is the boundary between them.

Claim	Verdict	Why
javac produces platform-neutral bytecode	True	Verified: no OS strings in the class file
Every platform has a JVM that runs it	Mostly true, with one glaring exception	Android is not a JVM
The JVM "interprets" bytecode	False	It JIT-compiles to native code
The standard library is uniform	False	Locale-sensitive methods return different results

The single most surprising result in this article is that the same bytecode file, run on the same machine, produces different output depending only on a system property. That is worth seeing before trusting the slogan in either direction.

2. Mechanism One: Bytecode Is Genuinely Neutral

This part is solid and worth verifying rather than assuming. I compiled a class and inspected the raw bytes:

Main.java

Run Online

magic: ca fe ba bemajor version: 61OS strings found: nonemd5: 0de51659b8c7beaea60fd33cf74dfc67

The class file contains **no operating-system strings whatsoever**. It has no path separators, no platform name, no native handle. That is not a coincidence but the design: the compiler's output targets an abstract instruction set described by the class file specification, so the same input produces the same output everywhere.

What makes this reliable is a set of **fixed-width guarantees** in the language specification, so that a value read on one platform means the same thing on another:

Type	Guaranteed width	Verified here
`int`	Always 32 bits, always two's complement	`Integer.BYTES = 4`
`long`	Always 64 bits	`Long.BYTES = 8`
`char`	Always unsigned 16-bit UTF-16 code unit	`Character.BYTES = 2`
`float` / `double`	IEEE 754, 32 and 64 bits	`Float.SIZE=32`, `Double.SIZE=64`
`boolean`	Not byte-addressable, unlike C	No `sizeof` equivalent

The IEEE 754 guarantee has a history worth knowing. Historically, strictfp existed because 32-bit x86 x87 FPU chips evaluated floating point at 80-bit extended precision, which meant the same arithmetic could produce different results on x86 and on stricter hardware. **JEP 306 made all floating-point expressions strict by default from JDK 17 onwards**, which retired the strictfp keyword's original purpose and made results reproducible across platforms without it.

3. Mechanism Two: The JVM Is Rebuilt Per Platform

The bytecode is portable because it targets an abstraction. Something has to translate it, and that something is a **native binary built separately for each operating system and CPU architecture**.

Platform	JVM library	Binary format
Linux x64	`libjvm.so`	ELF 64-bit (verified on this machine)
macOS	`libjvm.dylib`	Mach-O
Windows	`jvm.dll`	PE
Android	Not a JVM	DEX bytecode, ART runtime

And on the question of interpretation, the original was wrong to say the JVM "interprets and JIT-compiles" as if those were alternatives. **It does both, in sequence, and the JIT does nearly all the real work.** HotSpot starts by interpreting bytecode and profiling which methods are hot, then compiles those to native code with C2 while C1 compiles sooner at lower optimisation. Confirmed with -XX:+PrintCompilation:

Main.java

Run Online

33 1 3 java.lang.Object::(1 bytes)

Compilation begins within milliseconds of startup. This matters to the platform question because the native code the JIT emits is per-architecture: the same bytecode becomes x86-64 machine code on one machine and ARM64 on another.

4. The Android Exception

The original listed Android as having "a custom JVM built for its hardware architecture". This is the clearest factual error in the entry, and it appears in a great deal of beginner material.

**Android does not run a JVM.** It runs the **Android Runtime (ART)**, which executes **DEX bytecode**, a different format entirely. Historically that was **Dalvik**. Converting Java source to DEX requires a separate pipeline: javac to class files, then d8 or dx to DEX. A .class file will not run on Android directly.

Target	Compile step	Runtime
Desktop or server	`javac` → `.class`	JVM
Android	`javac` → `.class` → `d8` → `.dex`	ART

The Java *language* is still portable to Android; the *bytecode* is not. That distinction is the one most commonly blurred.

5. Where WORA Genuinely Breaks

Here is the part that matters in practice, and none of it was mentioned in the original.

**Locale-sensitive methods.** The classic demonstration, which I ran on one machine with one class file:

Main.java

Run Online

default locale = en_IN "title".toUpperCase() = TITLEdefault locale = tr_TR "title".toUpperCase() = TİTLE

Identical bytecode. Identical JVM. Different output, because the no-argument toUpperCase() consults the **default locale**, and Turkish has a dotless uppercase I. A method that passes a test in one region can fail in another for no apparent reason. This is not exotic: it has repeatedly broken real systems sorting user-facing text and comparing usernames.

**Default character encoding.** Verified on this machine:

Main.java

Run Online

file.encoding = UTF-8native.encoding = UTF-8line.separator = \nfile.separator = /path.separator = :

All four are platform-dependent, and one changed recently. **JEP 400 made UTF-8 the default file.encoding from JDK 18**, where before it followed the platform's locale. So code written against JDK 17 or earlier can behave differently when moved to 18+. Conversely, JDK 8's default is not UTF-8 on Windows, where it is typically windows-1252. Any code relying on the default rather than an explicit charset is relying on something that has changed across versions.

**String comparison.** "a".compareTo("B") returns **31**, not a negative number, because compareTo is a raw UTF-16 code-unit comparison. Humans expect "a" before "B". Getting linguistic ordering requires java.text.Collator, which is locale-dependent and therefore reintroduces platform dependence in exchange for correctness.

**Native code and file paths.** JNI libraries are per-platform binaries. Paths differ by separator, by case sensitivity (Windows and macOS are typically case-insensitive, Linux is not), and by reserved characters.

Difference	Linux	Windows
Path separator	`/`	`\`
Path case sensitivity	Case sensitive	Case insensitive
Line separator	`\n`	`\r\n`
Drive letters	None	`C:\`
Max path length	Deeply nested	Historically 260 chars

Case sensitivity alone causes real bugs: code that passes on Windows can throw FileNotFoundException on Linux because the filename case no longer matches.

6. Forward Compatibility: WORA Is One-Directional

Bytecode portability also has a direction, and this surprises people. **Old bytecode runs on new JVMs; new bytecode does not run on old JVMs.**

I compiled the same source targeting Java 8 and confirmed the class file version dropped to 52:

Main.java

Run Online

$ javac --release 8 -d r8 Wora.java -> class file major version 52$ java -cp r8 Wora running on Linux amd64

That ran perfectly on a JDK 17 JVM. The reverse fails:

Main.java

Run Online

UnsupportedClassVersionError: class file version 61.0,this JVM only understands up to 52.0

So "write once, run anywhere" holds within a floor, not a ceiling. A library compiled against a newer JDK will not run on an older one, which is exactly why --release exists: it compiles against the *API signatures* of an older release, not just older bytecode, so you catch accidental use of newer methods at build time.

Java release	Class major version
Java 8	52
Java 11	55
Java 17	61
Java 21	65
Java 25	69

Note the pattern: versions 45 to 51 are unreachable in practice, because Oracle abandoned the "1.x" numbering. A file with major 49 was Java 5, and no current JVM supports it.

One further subtlety appears only from Java 12 onwards: **minor version 65535 marks a class file compiled with preview features**, and such a class can only be loaded by a JVM of the *exact same* release with --enable-preview. So preview bytecode is the one case where WORA fails even when both sides are current.

7. A Fair Summary

The honest formulation of WORA is narrower than the slogan and more useful:

**Your bytecode is portable. Your source is not automatically correct on every platform.**

Guaranteed portable	Not guaranteed
Bytecode and class file format	Default charset (changed in JDK 18)
Primitive widths and IEEE 754 arithmetic	Locale-sensitive casing and sorting
Serializable object streams	Path syntax and case sensitivity
String is UTF-16 on every platform	Line separators and default locale
Forward compatibility with older JVMs	JNI native libraries
java.io, java.util, java.nio behaviour	Android, which needs DEX not class files

Worth checking on the portable side, since I verified it here: Java serialization streams really are byte-order independent. ObjectOutputStream writes the magic AC ED 00 05 in big-endian order, matching the specification's mandated DataInputStream behaviour, so a stream written on an x86 machine reads correctly on a big-endian one. That entry is genuinely portable, contrary to a common belief that serialization is endian-dependent.

The practical takeaway is that WORA is a guarantee about **where your code executes**, not a guarantee about **what it computes**. The execution target is uniform; the ambient environment of locale, encoding and filesystem is not.

Runnable Code Example: How Java Achieves Platform Independence

Java 17+

Main.java

Run Online

import java.io.*;
import java.nio.ByteOrder;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;
import java.util.Locale;
/**
 * "Write Once, Run Anywhere" is true about bytecode and false about behaviour.
 * This class demonstrates both halves on a single machine, with one class file.
 */public class WoraReality {
    public static void main(String[] args) throws Exception {
        System.out.println("==
1. THE PORTABLE HALF: this class file has no OS in it ==");
        System.out.println("   os.name / os.arch     = " + System.getProperty("os.name") + " " + System.getProperty("os.arch"));
        System.out.println("   String.class resource = " + ClassLoader.getSystemResource("java/lang/String.class"));
        System.out.println("   -> the bytecode is identical on every platform; only the JVM differs.");
        System.out.println("\n==
2. THE BROKEN HALF: same bytecode, different locale ==");
        Locale def = Locale.getDefault();
        System.out.println("   default locale       = " + def);
        System.out.println("   \"title\".toUpperCase() = " + "title".toUpperCase());
        System.out.println("   explicit en_US        = " + "title".toUpperCase(Locale.US));
        System.out.println("   explicit tr_TR        = " + "title".toUpperCase(Locale.forLanguageTag("tr-TR")));
        System.out.println("   -> Run me again with -Duser.language=tr -Duser.country=TR");
        System.out.println("      the no-arg form changes result. That is WORA failing, not a JVM bug.");
        System.out.println("\n==
3. DEFAULT CHARSET IS A PLATFORM/VISIBLE DEPENDENCY ==");
        System.out.println("   file.encoding        = " + System.getProperty("file.encoding"));
        System.out.println("   defaultCharset()     = " + Charset.defaultCharset());
        System.out.println("   JDK 18+ (JEP 400)    = UTF-8 regardless of platform");
        System.out.println("   JDK 17 and earlier   = follows the platform locale (windows-1252 on Windows)");
        System.out.println("   String itself is ALWAYS UTF-16 internally: \"e-acute\" = " + "é".getBytes(StandardCharsets.UTF_16).length + " bytes in UTF-16");
        System.out.println("\n==
4. compareTo is NOT linguistic ordering ==");
        System.out.println("   \"a\".compareTo(\"B\")            = " + "a".compareTo("B") + "   (positive: code-unit order)");
        System.out.println("   Collator.getInstance() = " + java.text.Collator.getInstance().compare("a", "B") + "   (human order, but locale-dependent)");
        System.out.println("\n==
5. PLATFORM-SPECIFIC SURFACES ==");
        System.out.println("   file.separator = " + esc(System.getProperty("file.separator")) + "   line.separator = " + esc(System.getProperty("line.separator")) + "   path.separator = " + esc(System.getProperty("path.separator")));
        System.out.println("   ByteOrder.nativeOrder() = " + ByteOrder.nativeOrder() + "  (not mandated by the spec)");
        System.out.println("   -> Windows: '\\\\', case-INSENSITIVE paths, drive letters, 260-char limit.");
        System.out.println("      Case sensitivity alone breaks code that works on both.");
        System.out.println("\n==
6. FIXED WIDTHS: why the portable half is reliable ==");
        System.out.println("   Integer.BYTES=" + Integer.BYTES + " Long.BYTES=" + Long.BYTES + " Character.BYTES=" + Character.BYTES);
        System.out.println("   float=" + Float.SIZE + "bits double=" + Double.SIZE + "bits (IEEE 754; strict since JEP 306 in JDK 17)");
        System.out.println("\n==
7. SERIALIZATION IS GENUINELY PORTABLE ==");
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        try(ObjectOutputStream oos = new ObjectOutputStream(bos)) {
            oos.writeObject("x");
        } byte[] stream = bos.toByteArray();
        int magic = new DataInputStream(new ByteArrayInputStream(stream)).readInt();
        System.out.println("   stream header = " + String.format("0x%08X", magic) + "  (ACED0005, written BIG-endian per spec)");
        System.out.println("   -> endian-independent, so streams cross architectures safely.");
        System.out.println("\n==
8. FORWARD COMPATIBILITY ONLY ==");
        System.out.println("   this class: major version " + classMajor());
        System.out.println("   old bytecode runs on new JVMs; new bytecode throws");
        System.out.println("   UnsupportedClassVersionError on old ones. Compile with --release 8");
        System.out.println("   to target Java 8 (major 52) while running on JDK 17.");
        System.out.println("\n==
9. ANDROID IS NOT A JVM ==");
        System.out.println("   Android runs ART on DEX bytecode, not class files.");
        System.out.println("   javac -> .class -> d8/dx -> .dex -> ART. One extra step, different runtime.");
    } static int classMajor() throws IOException {
        try(DataInputStream in = new DataInputStream( WoraReality.class.getResourceAsStream("/WoraReality.class"))) {
            in.readInt();
            in.readUnsignedShort();
            return in.readUnsignedShort();
        }
    } static String esc(String s) {
        StringBuilder b = new StringBuilder();
        for (char c : s.toCharArray()) {
            if (c == '\n') b.append("\\n");
            else if (c == '\r') b.append("\\r");
            else if (c == '\\') b.append("\\\\");
            else b.append(c);
        } return b.toString();
    }
}

Common Java Technical Interview Questions & Answers

Interview Prep

What is Java bytecode?

An intermediate, platform-neutral instruction set produced by javac and stored in a .class file, which the JVM executes. I inspected one directly: the magic number is ca fe ba be, the major version was 61 on Temurin 17, and critically it contained no operating-system strings at all, no path separators or platform names. That absence is the design working, since the compiler targets an abstract instruction set rather than any real machine. The neutrality is reinforced by fixed-width language guarantees, so int is always 4 bytes, long 8, char an unsigned 16-bit UTF-16 unit, and floating point strictly IEEE 754.

What is WORA in Java?

Write Once, Run Anywhere, meaning write the source once and run the compiled bytecode on any device with a JVM. The honest version is narrower than the slogan: your bytecode is genuinely portable, but your behaviour is not automatically correct everywhere. The execution target is uniform while the ambient environment is not, because locale, default charset, filesystem and path rules all differ. I demonstrated this by running one unmodified class file twice and getting TITLE under an English locale and TİTLE under tr-TR, since no-argument toUpperCase consults the default locale.

Does the JVM interpret bytecode or compile it?

It does both, and describing them as alternatives is a common misconception. HotSpot starts by interpreting and profiling, then JIT-compiles hot methods to native code, with C1 compiling sooner at lower optimisation and C2 later at higher optimisation. I confirmed compilation starts within milliseconds using -XX:+PrintCompilation, which showed java.lang.Object:: being compiled during startup of a bare java -version. This matters to portability because the native code the JIT emits is per-architecture, so the same bytecode becomes x86-64 machine code on one machine and ARM64 on another.

Is the standard library uniform across platforms?

No, and this is the answer most tutorials get wrong. I verified on one machine that file.encoding, native.encoding, file.separator, line.separator and path.separator are all environment-dependent. The clearest behavioural difference is locale-sensitive casing, where the same bytecode gives TITLE in English and TİTLE in Turkish. String ordering is another, since "a".compareTo("B") returns 31, a raw UTF-16 code-unit comparison, so human ordering needs java.text.Collator which is itself locale-dependent. The library provides a consistent API, not identical results.

What exactly changed in JDK 18 regarding encoding?

JEP 400 changed the default charset to UTF-8 regardless of platform or locale. Before it, file.encoding followed the platform's locale, which meant JDK 8 on Windows defaulted to windows-1252 rather than UTF-8. On this JDK 17 machine file.encoding and native.encoding both report UTF-8 because the platform locale happens to be UTF-8, which is a good illustration of why the old behaviour was unreliable. The practical consequence is that code relying on the default may behave differently after upgrading to 18, so pass an explicit Charset or StandardCharsets rather than relying on it.

Is Android a JVM?

No, and this is a factual error that appears in a lot of beginner material. Android runs the Android Runtime, ART, which executes DEX bytecode, a different format from class files. Historically that runtime was Dalvik. Getting from Java source to Android requires javac to produce .class files and then d8 or dx to convert those to .dex, so the Java language is portable to Android but the bytecode is not, and a .class file will not run there directly. Art also differs technically, using an ahead-of-time compiler plus a JIT, so it is not simply a different JVM.

Does old bytecode run on new JVMs?

Yes, and the reverse fails. I compiled a class with --release 8, confirmed its major version dropped to 52, and ran it successfully on a JDK 17 JVM. Running major version 61 bytecode on a Java 8 JVM instead throws UnsupportedClassVersionError saying the JVM only understands up to 52.0. So portability has a floor rather than a ceiling. For reference the major versions are 52 for Java 8, 55 for 11, 61 for 17, 65 for 21 and 69 for 25.

What about preview features?

Preview features are the one case where bytecode portability fails even between current releases. From Java 12 onwards a class file using preview features carries minor version 65535, and such a class can only be loaded by a JVM of the exact same release with --enable-preview. So a class compiled with --enable-preview on 21 will not run on 22 or 23. This is worth knowing if you see a class file with a minor version of 65535, since the major version alone will not explain the failure.

Why does string comparison behave surprisingly?

Because String.compareTo compares raw UTF-16 code units rather than letters, so "a".compareTo("B") returns 31, positive, meaning a sorts after B. That is correct for code-unit order and wrong for human expectations. Getting linguistic ordering requires java.text.Collator, and I verified it returns -1 for the same pair. The trade-off is that Collator results depend on locale, so code using it reintroduces environment dependence. Neither behaviour is a bug; they answer different questions, and picking the wrong one is.

Q10

What are the most common cross-platform bugs in practice?

Case sensitivity ranks first. Linux and macOS are typically case-sensitive and Windows is not, so code that passes on a Windows developer's machine can throw FileNotFoundException on a Linux server because the filename case differs. After that come line separators, since \n on Unix is \r\n on Windows and naive text comparisons or hash computations break. Then path separators and drive letters, JNI native libraries which must be rebuilt per platform, and locale-sensitive casing, which famously broke Turkish users of i uppercase conversion. All of these are avoidable but none are prevented by the compiler.

Q11

Is Java serialization portable across platforms?

Yes, and this is worth confirming because a common belief says otherwise. I wrote an object and read the first four bytes of the stream with DataInputStream.readInt, which returned the magic 0xACED0005. ObjectOutputStream writes that header in big-endian order to match the specification's mandated DataInputStream behaviour, so streams are byte-order independent and cross architectures safely. I briefly suspected the opposite while investigating endianness and checked the arithmetic before relying on it, which is the point: confirm before asserting in either direction. The real serialization portability risk is serialVersionUID evolution, not byte order.

Q12

What does --release actually do?

It sets both the bytecode version and the API surface you compile against, which is more important than the version alone. Using -source or -target alone lets you compile against a newer JDK's API while emitting old bytecode, so code can compile cleanly and then throw NoSuchMethodError on an older JVM at runtime. --release instead compiles against the older release's actual API signatures, so an accidental use of a newer method is caught at build time. I used it to produce a major version 52 class from JDK 17 and verified it ran on the same JVM.

Q13

Why is int always 4 bytes even on 64-bit systems?

Because the language specification fixes the width of primitive types, so int is always 32 bits and long always 64 bits regardless of the machine's word size. I verified Integer.BYTES=4, Long.BYTES=8 and Character.BYTES=2 at runtime. This is what allows bytecode to be portable, since there is no ambiguity about how a value on the stack or in a field should be interpreted. The historical exception was boolean, which is not byte-addressable the way C's is, but even that is spec-defined rather than platform-defined.

Q14

Summarise when WORA holds and when it does not.

WORA is a guarantee about where your code executes, not about what it computes. Portable: the bytecode and class file format, primitive widths, IEEE 754 arithmetic, String as UTF-16 everywhere, and serialization streams. Not portable: the default charset, which changed in JDK 18, locale-sensitive casing and sorting, path syntax and case sensitivity, line separators, and JNI libraries. And compatibility runs one way only, since old bytecode runs on new JVMs but not the reverse. Android sits outside it entirely because ART executes DEX rather than class files.

Key Takeaways, Best Practices & Clean Code Rules

Java Best Practice & Production Rules

Always pass an explicit `Locale` to `toUpperCase`, `toLowerCase`, `format` and `String.format`, because the no-argument forms consult the default locale and produce different results on the same bytecode; I verified `"title".toUpperCase()` returning `TITLE` under an English locale and `TİTLE` under `tr-TR`, and this class of bug has repeatedly broken production systems that were only ever tested in one region. Never rely on the default charset, since JEP 400 changed `file.encoding` to UTF-8 in JDK 18 whereas earlier releases followed the platform locale, typically windows-1252 on Windows; specify `StandardCharsets.UTF_8` explicitly for every stream, file and byte conversion so that upgrading a JDK cannot silently alter how your data is encoded. Use `java.text.Collator` rather than `String.compareTo` for anything user-facing, because `compareTo` is a raw UTF-16 code-unit comparison that returns a positive value for `"a"` against `"B"` and therefore sorts lowercase letters after uppercase, whereas `Collator` gives correct human ordering at the cost of locale dependence. Build paths with `Path` and `Files`, or at minimum with `File.separator`, and never by string-concatenating `"/"`, remembering that Windows uses `\` and `\r\n`, has drive letters, and is usually case-insensitive while Linux is case-sensitive; write a test that runs on a case-sensitive filesystem, since code that passes on Windows routinely fails on Linux servers with `FileNotFoundException`. Compile with `--release ` rather than `-source` and `-target`, because `--release` constrains both the bytecode version and the API surface you compile against, catching accidental use of newer methods at build time instead of letting them fail at runtime with `NoSuchMethodError` on an older JVM. Remember that compatibility runs one way only: old bytecode runs on new JVMs, so a class compiled for Java 8 with major version 52 executes fine on JDK 17, whereas major version 61 bytecode on a Java 8 JVM throws `UnsupportedClassVersionError`; pin your target release in the build rather than relying on whichever JDK the developer happens to have installed. Treat any dependency that ships native libraries as a portability constraint, since JNI code must be recompiled per operating system and CPU architecture and `include/jni.h` defines an ABI that is not portable; if you depend on such a library, verify it ships binaries for every platform you intend to support, and remember that Android is not a JVM at all because it runs ART on DEX bytecode requiring an extra `d8` conversion rather than executing `.class` files directly. Prefer cross-platform abstractions such as `java.nio.file`, the collections API and streams over shelling out to platform utilities with `Runtime.exec`, since each such call reintroduces exactly the OS dependence the bytecode layer was designed to remove; and when you do need native endianness, query `ByteOrder.nativeOrder()` explicitly rather than assuming little-endian, since the specification does not mandate it, while remembering that Java serialization streams themselves are safe, as their `0xACED0005` header is written in big-endian order per specification and therefore crosses architectures correctly.

Previous TopicJDK, JRE, and JVM Compared: Roles, Relationships, and Differences

Next TopicJava Editions Explained: SE, EE, ME, and FX Use Cases