From Python to Java: The Mental-Model Shift
You already know how to program. That's the good news and the trap: Java will feel familiar enough that you'll read your Python instincts straight into it — and wrong enough in ten specific places that those instincts will quietly betray you. This post is about those ten places. Not syntax — you can look up syntax. The mental models: what a variable is, what == means, when an error is allowed to exist, who cleans up your objects.
Every example below ran for real: JDK 21 (Temurin 21.0.12.1) and Python 3.12.3, outputs pasted from actual runs, no invented numbers. The lab sources live alongside this post so you can re-run anything that surprises you — and a few things should.
Start with the single biggest remap. In Python, a name is a sticky note slapped onto an object; the object carries the type, the name carries nothing. In Java, a variable is a typed slot: for primitives the value lives in the slot, for objects the slot holds a reference to a heap object — and the type is fixed at declaration, forever:
1. Compiled vs interpreted — what javac actually produces
In Python you write hello.py and the interpreter reads it fresh on every run. In Java there are two distinct steps, and conflating them causes half of beginners' confusion:
# hello_py.py
import sys
print("Hello from interpreted Python,", " ".join(sys.argv[1:]))// HelloJava.java
public class HelloJava {
public static void main(String[] args) {
System.out.println("Hello from compiled Java, " + String.join(" ", args));
}
}
$ python3 hello_py.py world
Hello from interpreted Python, world
$ javac HelloJava.java && java HelloJava world
Hello from compiled Java, worldjavac doesn't produce machine code — it produces bytecode, a compact instruction set for the JVM, stored in .class files:
$ ls HelloJava.class
HelloJava.class
$ file HelloJava.class
HelloJava.class: compiled Java class data, version 65.0Version 65.0 is the class-file version for Java 21. You can peek at the actual bytecode with javap -c — this is the real, complete disassembly of the main method above:
$ javap -c HelloJava
Compiled from "HelloJava.java"
public class HelloJava {
public HelloJava();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: getstatic #7 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #13 // String
5: aload_0
6: invokestatic #15 // Method java/lang/String.join:(Ljava/lang/CharSequence;[Ljava/lang/CharSequence;)Ljava/lang/String;
9: invokedynamic #21, 0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
14: invokevirtual #25 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
17: return
}Two things worth noticing. First, the whole program is a class — there is no "script mode"; main is just the agreed entry point. Second, even string + compiles to an invokedynamic bootstrap call — the compiler emits a recipe and the JVM decides the fastest strategy at runtime. That runtime half of "compiled" matters: the JVM's JIT compiler watches your hot loops and compiles them to native code while the program runs. A tight loop makes the difference visible. Same algorithm, both languages:
// SumLoop.java — sum 1..20,000,000 with a plain for loop
public class SumLoop {
public static void main(String[] args) {
int n = 20_000_000;
long t0 = System.nanoTime();
long total = 0;
for (int i = 1; i <= n; i++) total += i;
long ms = (System.nanoTime() - t0) / 1_000_000;
System.out.println("total=" + total + " in " + ms + " ms");
}
}# sum_loop.py — the same loop, interpreted
import time
n = 20_000_000
t0 = time.perf_counter()
total = 0
for i in range(1, n + 1):
total += i
ms = (time.perf_counter() - t0) * 1000
print(f"total={total} in {ms:.0f} ms")$ javac SumLoop.java && java SumLoop
total=200000010000000 in 98 ms
$ python3 sum_loop.py
total=200000010000000 in 2824 msSame total — 200000010000000 in both, so it's a fair race — and ~29x apart on this machine. The honest framing: Python executes each loop iteration as bytecode in the interpreter; the JVM's JIT compiled the Java loop to native machine code after a few warm-up iterations. (Yes, Java's 98 ms includes JVM startup; the loop itself is a few milliseconds.) And the Python caveat you already know: sum(range(...)) would run the loop in C and be dramatically faster — the gap here is interpreted loop vs JIT-compiled loop, not the languages' best tricks.
javac translates source to bytecode (catching type errors — see section 4), the JVM loads bytecode, and the JIT compiles hot paths to native code at runtime. "Compiled" in Java really means "compiled twice."2. Java is ALWAYS pass-by-value
This is the single most argued-about sentence in Java, and Python developers arrive pre-confused because the two languages behave identically here but describe it differently. Run this pair and compare the outputs line by line:
// SwapDemo.java
import java.util.ArrayList;
import java.util.List;
public class SwapDemo {
static void trySwap(int a, int b) {
int t = a; a = b; b = t;
System.out.println(" inside trySwap: a=" + a + ", b=" + b);
}
static void addItem(List<String> items, String item) {
items.add(item); // mutates the caller's object
items = new ArrayList<>(); // rebinds only the local copy of the reference
items.add("LOCAL ONLY");
System.out.println(" inside addItem, local list=" + items);
}
public static void main(String[] args) {
int x = 1, y = 2;
trySwap(x, y);
System.out.println("after trySwap: x=" + x + ", y=" + y);
List<String> cart = new ArrayList<>();
cart.add("apple");
addItem(cart, "banana");
System.out.println("after addItem: cart=" + cart);
}
}# swap_demo.py
def try_swap(a, b):
a, b = b, a
print(f" inside try_swap: a={a}, b={b}")
def add_item(items, item):
items.append(item) # mutates the caller's object
items = [] # rebinds only the local name
items.append("LOCAL ONLY")
print(f" inside add_item, local list={items}")
x, y = 1, 2
try_swap(x, y)
print(f"after try_swap: x={x}, y={y}")
cart = ["apple"]
add_item(cart, "banana")
print(f"after add_item: cart={cart}")$ javac SwapDemo.java && java SwapDemo
inside trySwap: a=2, b=1
after trySwap: x=1, y=2
inside addItem, local list=[LOCAL ONLY]
after addItem: cart=[apple, banana]
$ python3 swap_demo.py
inside try_swap: a=2, b=1
after try_swap: x=1, y=2
inside add_item, local list=['LOCAL ONLY']
after add_item: cart=['apple', 'banana']Identical behavior. The swap fails in both (you can't rebind the caller's names), the mutation succeeds in both (you can reach through and change the object). Python calls this "pass by object reference"; Java calls it what it mechanically is: pass by value, where the value being passed is the reference. The parameter is a fresh copy of the slot from the diagram above — copying the arrow, not the object.
items = new ArrayList<>() inside addItem would rebind the caller's cart. It doesn't — the output proves it. Java is always pass-by-value: primitives copy the value, objects copy the reference. There is no second mode.3. Identity vs equality: is/== becomes ==/.equals()
Here's the mapping table for your reflexes:
| Question | Python | Java |
|---|---|---|
| Same object? (identity) | x is y | x == y (for objects) |
| Same value? (equality) | x == y | x.equals(y) |
The trap is that Java's == on objects sometimes looks like a value comparison, because the JVM interns string literals — both literals point at one pooled object. Python does the same thing, which makes this a perfect mirror demo:
// EqualityDemo.java
public class EqualityDemo {
public static void main(String[] args) {
String a = "hello";
String b = "hello";
String c = new String("hello"); // explicitly NOT interned
System.out.println("literal == literal : " + (a == b));
System.out.println("literal == new : " + (a == c));
System.out.println("literal.equals(new): " + a.equals(c));
int i = 42;
long l = 42L;
System.out.println("int 42 == long 42L : " + (i == l));
}
}# equality_demo.py
a = "hello"; b = "hello"
c = "".join(["hel", "lo"]) # built at runtime: not interned
print("a is b (literal, interned):", a is b)
print("a is c (built at runtime):", a is c)
print("a == c:", a == c)
x, y = 100, 100 # small-int cache
print("small ints x is y:", x is y)
m, n = int("1000"), int("1000") # built at runtime: distinct objects
print("big ints m is n:", m is n)
print("big ints m == n:", m == n)$ javac EqualityDemo.java && java EqualityDemo
literal == literal : true
literal == new : false
literal.equals(new): true
int 42 == long 42L : true
$ python3 equality_demo.py
a is b (literal, interned): True
a is c (built at runtime): False
a == c: True
small ints x is y: True
big ints m is n: False
big ints m == n: TrueRead the two outputs as one lesson: in both languages, identity sometimes coincides with equality for literals (interning, small-int caching) and diverges for runtime-built values. Python trained you to use == for values and is only for None-style identity checks. Port that discipline directly: in Java, == on objects is is; .equals() is ==. The classic production bug is code that compares strings with ==, passes every unit test (literals intern), then fails on real user input (runtime-built strings don't). One more line from the output: for primitives, Java's == compares values, with numeric promotion — int 42 == long 42L is true. No .equals() exists for primitives; there's nothing to dereference.
4. Static typing: the compiler reads your code before your users do
This is the shift you feel in your fingertips. In Python the type lives on the object and a name can point at anything; in Java the type lives on the variable and the compiler enforces it. Write the obvious mistake and watch when you hear about it:
// TypeError.java
public class TypeError {
public static void main(String[] args) {
int x = "hi"; // does not compile: String cannot be converted to int
System.out.println(x);
}
}$ javac TypeError.java
TypeError.java:3: error: incompatible types: String cannot be converted to int
int x = "hi"; // does not compile: String cannot be converted to int
^
1 errorThe program never ran. No TypeError.class was produced, no traceback at 3 AM, no customer hitting the branch first. Compare with the Python equivalent, which is perfectly happy until the line executes:
# dynamic.py — legal Python; the error (if any) arrives at runtime
x = 1
print(x, type(x).__name__)
x = "hi"
print(x, type(x).__name__)
x = [1, 2]
print(x, type(x).__name__)$ python3 dynamic.py
1 int
hi str
[1, 2] listStatic typing moves a whole category of errors from "the line runs" to "the code compiles." The cost/benefit for a Python developer, stated plainly:
- Cost: you must declare types (
int x,List<String> cart), casts and generics add ceremony, and some designs that are two lines in Python need an interface in Java. - Benefit: the compiler becomes a test suite that runs before your tests do. Refactoring a method signature? Every caller that breaks is a compile error pointing at the exact line, not a
TypeErrordiscovered by whichever user clicks first.
You already know this trade: it's what type hints + mypy give you, except Java made it mandatory and the tooling free. And Java softened the ceremony with var — type inference, not dynamic typing. The compiler figures out the type from the initializer, then locks it:
// VarDemo.java
import java.util.ArrayList;
public class VarDemo {
public static void main(String[] args) {
var name = "Ada"; // inferred: String
var scores = new ArrayList<Integer>(); // inferred: ArrayList<Integer>
scores.add(9);
var total = 0; // inferred: int
for (var s : scores) total += s;
System.out.println(name + " scored " + total);
// name = 42; // uncomment: compile error — String vs int
}
}$ javac VarDemo.java && java VarDemo
Ada scored 9Uncommenting name = 42; fails to compile — var saved keystrokes, not type safety. Use it for locals with obvious types; keep explicit declarations where the type is the documentation.
5. Immutability: Strings, final, and the += lesson you already learned
Python taught you that str and int are immutable: s += "x" builds a new string. Java's String is immutable too — but Java adds a second, separate concept that Python lacks: final, which pins the binding, not the object.
| Python idea | Java equivalent | Notes |
|---|---|---|
Immutable str/int/tuple | Immutable String, primitives, records | Same instinct, applies directly |
| (no equivalent) — rebinding is always allowed | final String s = "hi"; | Pins the variable; the object may still be mutable |
"".join(parts) for building strings | StringBuilder | The +=-in-a-loop lesson, reprised |
That last row deserves real numbers, because Python developers already know this lesson and Java re-teaches it the hard way. Appending 30,000 characters one at a time:
// StringConcat.java
public class StringConcat {
public static void main(String[] args) {
int n = 30_000;
long t0 = System.nanoTime();
String s = "";
for (int i = 0; i < n; i++) s += "x";
long plusMs = (System.nanoTime() - t0) / 1_000_000;
System.out.println("+= in loop : length=" + s.length() + " in " + plusMs + " ms");
t0 = System.nanoTime();
StringBuilder sb = new StringBuilder();
for (int i = 0; i < n; i++) sb.append("x");
long sbMs = (System.nanoTime() - t0) / 1_000_000;
System.out.println("StringBuilder: length=" + sb.length() + " in " + sbMs + " ms");
}
}# str_concat.py
import time
n = 30_000
t0 = time.perf_counter()
s = ""
for _ in range(n):
s += "x"
print(f"+= loop : length={len(s)} in {(time.perf_counter()-t0)*1000:.0f} ms")
t0 = time.perf_counter()
parts = []
for _ in range(n):
parts.append("x")
s2 = "".join(parts)
print(f"list + join: length={len(s2)} in {(time.perf_counter()-t0)*1000:.0f} ms")$ javac StringConcat.java && java StringConcat
+= in loop : length=30000 in 315 ms
StringBuilder : length=30000 in 7 ms
$ python3 str_concat.py
+= loop : length=30000 in 19 ms
list + join: length=30000 in 2 msHere's the part I want to be honest about, because the numbers surprised me the first time: Java's += is 45x slower than StringBuilder here, while Python's += is only ~10x slower than join. Why? CPython cheats: when the string's reference count is 1 (the common loop case), it over-allocates and appends in place, so += is near-amortized-constant. Java performs no such optimization for += across loop iterations — every iteration allocates a brand-new String and copies everything so far, genuinely quadratic. (Within a single expression like "a" + b + "c", javac does use one builder — the invokedynamic recipe from section 1.) The rule for both languages is the same — accumulate in a builder, join once — but in Java the penalty for ignoring it is severe and the fix is one class: StringBuilder.
final vs immutable — don't merge them. final List<String> cart = new ArrayList<>() means you can't rebind cart to another list; you can still cart.add(...) all day. Immutability is a property of the object (String, records); final is a property of the variable. Python has neither spelling — which is why this distinction feels new.6. Overloading, constructors — and Java's own == trap
Python gives a class one __init__ and leans on default arguments for flexibility. Java takes the opposite approach: multiple constructors, plus method overloading — same name, different parameter lists, resolved by the compiler at the call site:
// OverloadDemo.java
public class OverloadDemo {
static String describe(int n) { return "int:" + n; }
static String describe(long n) { return "long:" + n; }
static String describe(String s) { return "String:" + s; }
static class Order {
String id; double total; String note;
Order(String id) { this(id, 0.0); } // chains to 2-arg
Order(String id, double total) { this(id, total, "n/a"); } // chains to 3-arg
Order(String id, double total, String note) {
this.id = id; this.total = total; this.note = note;
}
public String toString() { return id + "/" + total + "/" + note; }
}
public static void main(String[] args) {
System.out.println(describe(7));
System.out.println(describe(7L));
System.out.println(describe("seven"));
System.out.println(new Order("A1"));
System.out.println(new Order("A2", 49.99));
System.out.println(new Order("A3", 49.99, "gift"));
}
}# init_demo.py — one __init__ with defaults does the same job
class Order:
def __init__(self, id, total=0.0, note="n/a"):
self.id, self.total, self.note = id, total, note
def __repr__(self):
return f"{self.id}/{self.total}/{self.note}"
print(Order("A1"))
print(Order("A2", 49.99))
print(Order("A3", 49.99, "gift"))$ javac OverloadDemo.java && java OverloadDemo
int:7
long:7
String:seven
A1/0.0/n/a
A2/49.99/n/a
A3/49.99/gift
$ python3 init_demo.py
A1/0.0/n/a
A2/49.99/n/a
A3/49.99/giftNotes for the Python eye: a constructor has the class's name and no return type — not even void. this(...) as the first line chains to another constructor, which is how Java spells "default arguments." Overloading is resolved statically: the compiler picks the method from the declared argument types, not runtime types — the opposite of Python's dynamic dispatch, and a common source of "but I passed a subclass!" confusion.
And now Java's own trap — the one that bites Python developers precisely because they just learned section 3. Autoboxing converts int to Integer silently, and the JVM caches Integer objects for -128..127:
// IntegerCacheTrap.java
public class IntegerCacheTrap {
public static void main(String[] args) {
Integer a = 127, b = 127; // autoboxed, inside the cache range
Integer c = 128, d = 128; // autoboxed, OUTSIDE the cache range
System.out.println("Integer 127 == 127 : " + (a == b));
System.out.println("Integer 128 == 128 : " + (c == d));
System.out.println("Integer 128 .equals : " + c.equals(d));
}
}$ javac IntegerCacheTrap.java && java IntegerCacheTrap
Integer 127 == 127 : true
Integer 128 == 128 : false
Integer 128 .equals : true== on boxed integers is true for 127 and false for 128 — same code, different answer, depending on a cache you didn't ask for. Python developers will feel a jolt of recognition: this is exactly your small-int cache from section 3's Python output (x is y true for 100, false for 1000). Both languages cache small integers as an optimization; both punish you for testing identity when you meant equality. The rule survives the port: objects get .equals(), always.
def f(items=[]) bug has no Java equivalent (each constructor call runs fresh code; there's no shared default object). Java's replacement traps are the Integer cache above and == on Strings from section 3. Different language, same lesson: identity is not equality.7. Checked vs unchecked exceptions — the compiler reads your error handling too
Python has one exception philosophy: raise anything, catch what you want, and the interpreter never checks. Java splits the world in two, and the compiler enforces the split:
- Checked exceptions (
IOException,SQLException, …) — the method declares them, and every caller must catch or re-declare. The compiler refuses to build otherwise. - Unchecked exceptions (
NullPointerException,IllegalArgumentException, … — allRuntimeExceptions) — behave like Python: raise and catch freely, no compiler involvement.
Watch the compiler act as a reviewer:
// CheckedFail.java
import java.io.FileReader;
public class CheckedFail {
public static void main(String[] args) {
FileReader r = new FileReader("nope.txt"); // compile error: unreported IOException
System.out.println(r);
}
}$ javac CheckedFail.java
CheckedFail.java:5: error: unreported exception FileNotFoundException; must be caught or declared to be thrown
FileReader r = new FileReader("nope.txt"); // compile error: unreported IOException
^
1 errorMeanwhile the unchecked version compiles without a whisper and explodes at runtime — note how helpful the message is (JDK 14+ "helpful NullPointerExceptions" pinpoint the null expression):
// UncheckedOk.java
public class UncheckedOk {
public static void main(String[] args) {
String name = null;
System.out.println("length=" + name.length()); // compiles fine, explodes at runtime
}
}$ javac UncheckedOk.java && java UncheckedOk
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "<local1>" is null
at UncheckedOk.main(UncheckedOk.java:4)The idiomatic fix for the checked case is try-with-resources — Java's answer to Python's with open(...), closing the resource automatically:
// CheckedFixed.java
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
public class CheckedFixed {
public static void main(String[] args) {
try (BufferedReader br = new BufferedReader(new FileReader("data.txt"))) {
String line = br.readLine();
System.out.println("first line of file: " + line);
} catch (IOException e) {
System.out.println("could not read file: " + e.getMessage());
}
}
}$ javac CheckedFixed.java && java CheckedFixed
first line of file: first lineexcept-less call can. Unchecked exceptions are for bugs (null dereference, bad argument) — catching them everywhere would just be ceremony. Rule of thumb until the Core track's deep dive: if the caller could reasonably recover, make it checked; if it means the code is wrong, make it unchecked.8. Packages: Python modules with a dress code
Python's import finds modules by file path; Java's packages work the same way, but the dress code is strict:
- One public class per file, and the filename must match the class name (
Cart.javaholdspublic class Cart). The compiler locates public classes by filename — break the rule and the lookup breaks. - The directory mirrors the package:
package com.example.shop;lives incom/example/shop/. importin Java only shortens names —import java.util.List;lets you writeListinstead ofjava.util.List. Unlike Python, it executes nothing.
// com/example/shop/Cart.java
package com.example.shop;
import java.util.ArrayList;
import java.util.List;
public class Cart {
private final List<String> items = new ArrayList<>();
public void add(String item) { items.add(item); }
public int size() { return items.size(); }
@Override
public String toString() { return items.toString(); }
}
// com/example/shop/Checkout.java
package com.example.shop;
public class Checkout {
public static void main(String[] args) {
Cart cart = new Cart();
cart.add("book");
cart.add("pen");
System.out.println("cart=" + cart + " items=" + cart.size());
}
}$ javac -d classes com/example/shop/Cart.java com/example/shop/Checkout.java
$ find classes -name "*.class"
classes/com/example/shop/Cart.class
classes/com/example/shop/Checkout.class
$ java -cp classes com.example.shop.Checkout
cart=[book, pen] items=2-d classes tells javac to lay the .class files out in package-mirroring directories; -cp classes puts them on the classpath; and you launch with the fully qualified name com.example.shop.Checkout. Python parallel: a package is a directory with an __init__.py; Java's near-equivalent is package-info.java (rarely needed, mostly for documentation). The deeper parallel is the module search path: Python's sys.path is Java's classpath — the list of directories and jars the JVM searches for classes. When a Java beginner hits ClassNotFoundException, it's the same disease as Python's ModuleNotFoundError: the runtime looked where you told it to, and the thing wasn't there.
9. Garbage collection: both languages clean up — differently
Python developers sometimes assume GC is the scary new thing in Java. It isn't: CPython has garbage collection too — reference counting (objects die the moment their last reference goes away) plus a cyclic collector for reference cycles. Java skips refcounting and uses tracing collectors: periodically, the JVM walks from your live roots (stack variables, static fields) and reclaims everything unreachable.
The default collector, G1, is generational: new objects go in the "young generation," and since most objects die young, most collections only scan that small region. This program allocates ~8 MB of short-lived arrays per round (~40 MB total across all 5 rounds) — textbook young garbage — run with GC logging on:
// GcDemo.java
public class GcDemo {
public static void main(String[] args) {
long kept = 0;
for (int round = 0; round < 5; round++) {
// ~8 MB of objects that die at the end of each round: textbook "young garbage"
byte[][] garbage = new byte[2000][];
for (int i = 0; i < garbage.length; i++) garbage[i] = new byte[4096];
kept += round;
}
System.out.println("done, kept=" + kept);
}
}$ javac GcDemo.java && java -Xlog:gc GcDemo
[0.003s][info][gc] Using G1
[0.093s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 7M->6M(126M) 12.812ms
[0.099s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 11M->8M(126M) 2.680ms
[0.102s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 15M->8M(126M) 1.890ms
done, kept=10Read the log like a Python dev reading gc.get_stats(): three young-generation pauses, the longest 12.8 ms, each reclaiming the dead arrays while the program kept running. Those timings are from one run on this machine — I'm not claiming them as benchmarks, just showing you what the machinery looks like when you ask to see it (-Xlog:gc is always available; no profiler needed).
The conceptual takeaway, no invented numbers: Java's collectors are tuned for throughput and pause-time goals you can configure (-XX:MaxGCPauseMillis), and the JVM picks ergonomics from your machine's cores and RAM. You don't manage memory in either language — but in Java, when latency matters, you can read the GC log and tune the collector, whereas CPython's refcounting gives you immediacy instead of tunability. Different trade, same "don't think about malloc" deal.
10. Records: dataclasses, but the compiler writes them
One paragraph, because post 2 covers this properly: if you love Python's @dataclass, Java's record is the same idea with the compiler doing the writing — constructor, accessors, equals/hashCode, and toString, all generated, all final:
// RecordTeaser.java
public record RecordTeaser(String id, double total) {
public static void main(String[] args) {
var o1 = new RecordTeaser("A1", 49.99);
var o2 = new RecordTeaser("A1", 49.99);
System.out.println(o1);
System.out.println("equals: " + o1.equals(o2));
}
}$ javac RecordTeaser.java && java RecordTeaser
RecordTeaser[id=A1, total=49.99]
equals: trueOne line declared the shape; the output shows value equality and a readable toString for free. Post 2 — Types, Generics & Nullability — takes records, generics, and null-handling apart properly.
The cheat sheet: Python concept → Java equivalent
| Python | Java | Section |
|---|---|---|
python app.py (interpreted) | javac App.java && java App (bytecode + JIT) | 1 |
| Name → object (dynamic binding) | Typed variable: primitive slot or reference | intro |
| "Pass by object reference" | Always pass-by-value (references are copied) | 2 |
x is y (identity) | x == y on objects | 3 |
x == y (equality) | x.equals(y) | 3 |
Dynamic rebinding (x = 1; x = "hi") | Static types; var infers but locks; final pins a binding | 4, 5 |
Immutable str | Immutable String; build with StringBuilder | 5 |
"".join(parts) | new StringBuilder()...toString() | 5 |
__init__ with default args | Constructors (class-named, no return type), chained with this(...) | 6 |
def f(a) / *args | Overloaded methods — resolved at compile time | 6 |
try/except (all unchecked) | try/catch; checked exceptions must be handled | 7 |
with open(...) | try (...) { } — try-with-resources | 7 |
import package.module | import com.example.Foo; — name shortening only | 8 |
Module file cart.py | One public class per file: Cart.java | 8 |
sys.path | Classpath (-cp) | 8 |
| Refcounting + cyclic GC | Tracing, generational GC (G1 default); -Xlog:gc to watch | 9 |
@dataclass | record (post 2) | 10 |
None | null (nullability discipline: post 2) | 2 |
list / dict / set | ArrayList / HashMap / HashSet (collections: post 3) | — |
pip + venv | Maven / Gradle (build tooling: post 4) | — |
Field check
Reading gives you the map; running gives you the reflexes. Do all five on your own machine (JDK 21, Python 3 — the lab sources for this post are your starter kit):
- Predict, then run. Before running: what does
System.out.println(new String("x") == "x")print, and why? What about"x" == "x"? Write both predictions down, run them, and explain any wrong prediction using the words interning and identity. - The unswappable box. Write a Java method
void swap(Integer a, Integer b)that tries to exchange the two values. Run it and confirm the caller's variables don't change. Then write the two-sentence explanation of why it cannot work — it must mention both pass-by-value and immutability. - Feel the quadratic. Bump
StringConcat'snto 100,000 and predict the+=time before running. (Hint: quadrupling the work of a quadratic algorithm does not quadruple the time.) Run it, compare withStringBuilderat the samen, and compute both ratios. - Let the compiler review you. Write a program that opens a file with
new FileReader(...)and notry/catch. Read the compiler's error message word by word — it's telling you the two legal fixes. Apply the try-with-resources fix and re-run. - Package it yourself. Move
SwapDemointo packagebridge(directorybridge/,package bridge;at the top), compile withjavac -d classes, and run it with the fully qualified name. Then deliberately break the one-public-class-per-file rule (two public classes, one file) and read whatjavacsays.
What's next
You've remapped the fundamentals: compilation, references, equality, typing, immutability, overloading, exceptions, packages, and garbage collection. Next we go deeper on the type system itself — the part of Java that repays study the fastest:
Next post: Types, Generics & Nullability — primitives vs wrappers, generics (Java's answer to "but what type is in the list?"), records in full, and a null-handling discipline so NullPointerException stops being your most common stack trace.
Continue: Java Learning Roadmap 2026
The roadmap is the full track order — Core Java, Spring Boot & APIs, Tooling & Testing, Concurrency & JVM, Data & Messaging, Production Java, and this Python-developers bridge. Come back to it whenever you need the map.
Comments
Post a Comment