Python.CodeCompared.To/Java

Read the ceremony left to right and none of it is arbitrary. public means the launcher, which is outside your class, is allowed to call it. static means it can be called without anyone constructing a Main first — a chicken-and-egg problem Python never has, since there is no object at module level either. void means it returns nothing (the exit status comes from System.exit, not from a return value). String[] args is Python's sys.argv[1:], minus the program name. The class name and the file name must match, so this file is Main.java.

The mixed-type concatenation works because Java converts the other operand to a String automatically when either side of + is one. That convenience is also a trap: "total: " + 1 + 2 yields total: 12, because + is left-associative and the first + has already turned the expression into a string. Python raises a TypeError for "total: " + 1 and so never lets that mistake compile in the first place.

Two differences worth internalizing. First, %n rather than \n: it emits the platform line separator, and printf does not append one on its own the way println does. Second, an f-string is checked when the module is compiled — a missing name is a NameError you find immediately — whereas a printf format string is a plain string checked at run time, so %d against a String throws IllegalFormatConversionException only when that line executes. Java also offers "%s scored %.1f".formatted(name, score), which returns the string instead of printing it.

Java computes the minimum indentation across all lines including the closing delimiter and removes that much from each. Moving the closing """ left therefore changes the content of the string — the delimiter position is part of the literal's meaning, which surprises everyone once. The opening """ must be followed by a newline, so a text block always starts on the line below.

The pay-off for the wait is that a whole category of Python bug — the misspelled attribute on the error path that nobody exercised — cannot reach production. The cost is the wait itself, and the loss of the read-eval-print habit. Java's jshell exists and is genuinely useful for a quick experiment, but no team develops in it the way a Python team lives in a REPL or a notebook. Note the last form: java Main.java runs a single source file directly, but it executes the first class in the file, which is why every example on this page puts Main first.

Notice what moves as a result. In Python the two commented-out calls would be genuine run-time events — one silently produces an int where a float was promised, and the other raises where the annotation said it would not. In Java they are text the compiler rejects, so the entire class of test that exists to check "what happens when the wrong type gets in here" simply has no subject. That is the trade the whole language makes: the errors you spend the most time on move from the log file to the build output, and in exchange you write the types down.

The distinction matters most when reading unfamiliar code. In Python, knowing what result holds means tracing every assignment that could have reached this line. In Java the declaration is the answer, and var is precisely the case where the declaration stops being the answer — which is why house styles usually allow it where the right-hand side names the type anyway (var reader = new BufferedReader(...)) and discourage it where it does not (var value = compute()).

Each primitive has a matching wrapper class (int/Integer, double/Double), and the compiler converts between them silently, which is called autoboxing. That silence has a price a Python programmer will not expect: a List<Integer> of a million values is a million separate heap objects, so the loop that would be a flat array in NumPy is a pointer chase in Java too — the reason libraries offer IntStream and int[] alongside the generic versions. Boxing also means a boxed value can be null, so unboxing one throws NullPointerException where the primitive could not.

Java's error message is the better of the two, and it is recent. Since Java 14, helpful NullPointerExceptions name the exact expression that was null — "Cannot invoke String.length() because is null" — where the old message was a bare line number that told you a chain of five calls contained a null somewhere. Note also that a primitive int cannot be null at all, so the Python habit of using None as "no value yet" has no equivalent for numbers unless you box them or reach for Optional, which the Error Handling section covers.

final freezes the binding, not the object — exactly the distinction Python programmers already know from tuples containing lists. A final List<String> cannot be pointed at a different list, but you can still add to the one it holds; for that you want List.copyOf(...), whose result throws on modification. The convention of naming constants in capitals is shared by both languages; only in Java is it backed by anything.

The two mechanisms are not interchangeable, and confusing them is a common early mistake: (int) "42" does not compile, because a String is not a number in disguise — you must parse it. Conversely (int) 7.9 is a cast that discards the fraction, which is Python's int(7.9), while Math.round is Python's round. Bad input behaves comparably in both: int("abc") raises ValueError, Integer.parseInt("abc") throws NumberFormatException.

Compare the two outputs line by line: where Python prints the next number up, Java prints the most negative value of the type. The defence is to know your ranges — an int stops just above two billion, which a row count, a millisecond timestamp, or a byte total will pass without ceremony — and to reach for long early. When you truly cannot bound the value, BigInteger gives you Python's behaviour explicitly, at roughly an order of magnitude in speed. If you would rather fail loudly than wrap, Math.addExact and its siblings throw ArithmeticException on overflow.

Two traps live here, and the second is subtler. First, 7 / 2 is 3 in Java, so an average computed from two int counters is quietly wrong unless one side is a double. Second, the rounding directions differ: Python's // floors toward negative infinity, giving -4, while Java truncates toward zero, giving -3. That also flips the sign of the remainder — Python's -7 % 2 is 1, Java's is -1 — so a hash bucket computed with % can come out negative in Java and index out of bounds. Use Math.floorMod for Python's answer.

The lesson carries over unchanged: never compare currency with ==, and use the exact decimal type when the answer has to match an accountant. The divergence is in the constructor. Decimal(0.1) in Python and new BigDecimal(0.1) in Java both capture the binary approximation with all its garbage digits; the string forms, Decimal("0.1") and new BigDecimal("0.1"), are the ones you want. Java additionally has no operators for BigDecimal, so arithmetic is add, subtract, multiply and a divide that demands you name a rounding mode.

Two habits to unlearn. Math.max and Math.min take exactly two arguments, so the Python idiom max(a, b, c) becomes a nested call or IntStream.of(a, b, c).max(). Watch the second line of output, too: Python's math.floor and math.ceil return integers, while Java's return double, so they print 3.0 4.0 and need a cast to (int) if an integer is what you wanted. And round is not a formatting function in Java — Math.round returns a whole number, so rounding to four decimal places for display is printf's job, as here, or BigDecimal.setScale when the rounded value itself is what you need.

The reason it costs so much is that the wrong version usually works. Java interns string literals, so "hello" == "hello" really is true, and code comparing constants with == passes every test until the day one of the strings arrives from a file, a socket or a database — at which point it is a different object and the comparison silently turns false. The strings had to be built at run time here precisely to make the difference visible. The rule is unconditional: use .equals for every object comparison, and reserve == for primitives and for the rare deliberate identity check. Objects.equals(a, b) does the same thing while tolerating a null on either side.

Java's compiler does rewrite a simple a + b + c in one expression into efficient code, but it cannot rewrite an accumulation across loop iterations — that really is quadratic, exactly as in Python. StringBuilder is the ordinary tool, not an optimization of last resort, and it is worth knowing it also has insert, reverse and deleteCharAt, which have no direct string equivalents. Its thread-safe sibling StringBuffer is a legacy class you will meet in old code and should not reach for.

Java's naming is camel case throughout (toUpperCase, startsWith, indexOf), and length is a method on a String — length() — but a bare field on an array, array.length, with no parentheses. That inconsistency is a fossil of the primitive/object split and trips everyone once. strip() is the Unicode-aware modern version; the older trim() only removes characters below U+0020 and is best avoided in new code.

When the separator is punctuation, wrap it in Pattern.quote(".") or escape it, or you will get an array of empty strings and no error. Two more asymmetries: join is a static method taking the separator first (String.join(" | ", names)), the mirror image of Python's " | ".join(names); and printing a Java array directly gives you a useless [Ljava.lang.String;@1b6d, which is why Arrays.toString appears here. Java's split also drops trailing empty strings by default, where Python's keeps them.

Both are half-open, so substring(0, 5) and text[0:5] agree exactly. The failure modes differ sharply, though: an out-of-range Python slice quietly clamps, so text[0:999] returns the whole string, while substring(0, 999) throws StringIndexOutOfBoundsException. Code ported directly from Python tends to discover this on the short input nobody tested.

Look at the second line of output: first + 1 is 105, not "h1" and not "i", because char promotes to int in arithmetic. Getting a character back requires the cast on the third line. The same promotion is why System.out.println('a' + 'b') prints 195. Being 16 bits, a char also cannot hold an emoji or any other character above U+FFFF — those occupy two char values, so length() counts UTF-16 units rather than characters, where Python counts code points.

The habit pays off when the implementation should change: swapping new ArrayList<>() for new LinkedList<>() touches one line, because nothing downstream depends on more than the interface. Note the empty diamond <>, which asks the compiler to infer String from the declaration. There is no indexing syntax — names.get(0), not names[0], since Java has no operator overloading — and no negative indices. The printed forms differ slightly: Java has no repr, so its list prints [Ada, Grace, Alan] with the strings unquoted.

An array's length is fixed at creation and there is no add; growing means allocating a new array and copying, which is exactly what ArrayList does for you internally. A new int[] is zero-filled and a new String[] is null-filled — there is no uninitialized-memory hazard as in C. You will meet arrays mainly in three places: String[] args, APIs that predate collections, and performance-sensitive numeric code. For everything else, reach for List.

getOrDefault is the direct equivalent of dict.get(key, default) and is worth making a reflex. The class choice also matters more than it looks: a plain HashMap has no defined iteration order, so a loop over one prints in an order that can change between runs, while Python dictionaries have preserved insertion order since 3.7. LinkedHashMap, used here, is the class that matches what you are used to; TreeMap keeps keys sorted. Also note that the key and value types are written out — Map<String, Integer> — and that the value type must be the boxed Integer, never int.

That last point is the trap. first.retainAll(second) is Python's first &= second, not first & second, so computing an intersection without destroying an operand means copying first — which is what the new TreeSet<>(first) calls do here. The three you need are retainAll (intersection), addAll (union) and removeAll (difference). TreeSet keeps its elements sorted, which is why the printed output is stable; a HashSet would print in an unspecified order, exactly as an unsorted Python set does.

The second printed line shows what the record gives you free: toString, equals and hashCode are generated, so a record prints as DivisionResult[quotient=3, remainder=2] rather than as an address. Before records arrived in Java 16 this pattern meant a twenty-line class or an Object[], which is why so much older Java code returns a mutable out-parameter or a Map instead. There is still no destructuring at assignment — but there is in a switch, which the Pattern Matching section shows.

So fixed.set(0, "c") compiles perfectly and fails at run time, which is exactly the shape of bug Java's type system usually eliminates. The practical consequence is that "is this list safe to modify?" is not answerable from a signature — a method taking a List<String> cannot tell whether it was handed an ArrayList or a List.of. Defensive copying (new ArrayList<>(incoming)) is the conventional answer. List.of, Map.of and Set.of also reject null elements outright, which the older Collections.unmodifiableList wrapper does not.

Note the bare String grade; declaration before the branch. Java requires a variable to be declared before use and will refuse to compile a read of one the compiler cannot prove was assigned on every path — remove the else here and the build fails with "variable grade might not have been initialized". Python has no such check, so the equivalent mistake is a NameError on the one input that takes the missing branch. The conditional expression reads backwards from Python's: condition first, then the two results.

This removes a whole family of Python bugs by construction. The classic is if not count: firing when count is legitimately 0 rather than missing, and its cousin where an empty list and None are indistinguishable to an if. In Java the three tests above are visibly three different questions, and a null check is a separate, explicit names != null. The cost is verbosity: if (names != null && !names.isEmpty()) is a very common line, and there is no shorter way to write it.

The enhanced form is the one to reach for, and the counting form only when you genuinely need the index — which is also the answer to enumerate, since Java has no equivalent. Two habits worth keeping: < rather than <= in the test, matching range's half-open behaviour, and never modifying the collection inside an enhanced for, which throws ConcurrentModificationException on the next iteration where Python's equivalent silently skips elements. break and continue work as you expect; the for ... else clause has no counterpart.

Java also has the ++ and -- operators, which Python deliberately omits; countdown-- is countdown -= 1. Note the semicolon after the closing while of a do-while — it ends a statement, and leaving it off is a compile error rather than a silent change of meaning. Labelled break (outer: for (...) { ... break outer; }) exists too, and is the tidiest way out of a nested loop; Python needs a flag or an exception for that.

That last point is the real difference. A Python match with no case _ simply falls off the end and returns None, which is a run-time surprise; a Java switch expression without a default is a compile error unless the compiler can prove the cases are exhaustive, which it can for an enum or a sealed type. If you meet the older colon form (case "Friday": with break), that is the C-style statement switch, where forgetting break falls through to the next case — the arrow form exists precisely to kill that bug.

The third Python call is the point of the row. add("2", "3") returns "23", because + means whatever the operands say it means and nobody wrote down what add was for. The Java version cannot be called that way at all, and if you want both behaviours you write both methods — see overloading, next. A method returning nothing is declared void; falling off the end of a non-void method is a compile error, where a Python function that forgets to return quietly hands back None.

The idiomatic shape is the one above — the short overload delegates to the long one, so the default lives in exactly one place. This resolution happens entirely at compile time, which has a consequence worth knowing: given Object thing = "text";, a call show(thing) chooses the Object overload even though the value is a String, because only the declared type is consulted. Python's dispatch, having no types to consult, cannot be surprised this way. For a constructor with many optional parts, Java's answer is usually a builder rather than a dozen overloads.

Spreading an existing sequence is where they differ in feel. Python needs the explicit *values; Java takes the array directly, because a varargs parameter is an array — passing one is the ordinary call, not a special form. The restrictions are that a varargs parameter must come last and there can only be one. The absence of keyword arguments is the bigger loss day to day: a Java call with five positional arguments is genuinely harder to read than the Python equivalent, which is why builders and records show up so often in well-written Java.

Java calls this "pass by value", meaning the reference value is copied; Python calls it "pass by object reference" or "call by sharing". Same behaviour, two vocabularies, and no language here passes by reference in the Pascal or C++ sense — there is no way to write a method that reassigns the caller's variable. Java's primitives make this less confusing than Python's immutables, since a copied int obviously cannot be changed; the mental model that survives both languages is "the argument is copied, the object is not".

The practical effect is that the Java version usually succeeds where the Python one does not, because a default JVM thread stack holds roughly ten thousand frames of a small method. Neither language eliminates tail calls, so deep recursion is a loop in both if you want to be safe. Note that Java's failure is an Error, not an Exception: catching it as done here is legal but conventionally wrong, since Error means the runtime is in trouble rather than your logic.

Two things follow from declaring fields up front. The set of fields is fixed, so you cannot attach a new attribute to an instance later the way Python allows (there is no __dict__ to add to, and no need for __slots__ to prevent it). And because they are declared, the compiler knows their types everywhere, which is what makes rectangle.area() checkable. The receiver is called this and is implicit — it appears in the constructor only to distinguish the field from the same-named parameter, where Python's self must be written every time and declared as the first parameter of every method.

There are four levels, and the default is the one nobody names: public (everyone), protected (subclasses and the same package), package-private (no keyword at all — the same package only, which is what balance() above is), and private (this class). Because the compiler enforces them, the accessor-method style is genuinely load-bearing rather than ceremonial: changing a field's representation behind balance() cannot break a caller, whereas in Python you would reach for @property to achieve the same thing after the fact. Reflection can still defeat private at run time, but nothing in ordinary code can.

@Override is optional and you should always write it. It asks the compiler to verify that the method really does override something, which turns a typo — speaks() instead of speak() — from a method that is silently never called into a build failure. Python has no equivalent check, and that particular bug is a familiar one. The other structural difference is that Java allows only one superclass; where Python reaches for multiple inheritance and mixins, Java uses interfaces with default methods, and there is no method resolution order to reason about.

Java has only the one method where Python has two: __str__ for humans and __repr__ for developers, with the latter used inside containers. If you need both in Java you write a second method with a name of your choosing and call it deliberately. Writing toString is not optional in practice — a log line or an assertion failure that prints Color@1b6d3586 tells you nothing, and this is the most common reason a debugging session in unfamiliar Java code starts badly. Records, in the next section, generate it for you.

Two Java-specific details. The parameter of equals is Object, not Color — writing equals(Color other) compiles as an overload that collections never call, which is the classic silent failure and exactly what @Override catches. And Python has a safety net Java does not: defining __eq__ without __hash__ makes the class unhashable, so the mistake shows up as a TypeError the first time you put one in a set, whereas Java's inherited identity hash keeps working and simply gives the wrong answer. In modern code the honest advice is to avoid writing either method by hand — use a record, which generates both correctly.

There is no direct equivalent of @classmethod, because cls exists to support subclass-aware factories and Java resolves static calls against the declared type at compile time — a static method is not overridden, only hidden. A subtler difference concerns the shared field: Counter.total is one variable in both languages, but in Python an instance assignment such as counter.total = 5 creates a new instance attribute that shadows the class one, while in Java it writes straight through to the single static field. The Python bug where a class-level list is accidentally shared between all instances has an exact Java counterpart in a static collection.

The trade is explicitness against reach. Java's version cannot be handed an object from a library that has an area() method but does not implement Shape; Python's can, which is what makes so much of the ecosystem compose without coordination. In exchange, totalArea's signature documents exactly what it needs, and adding a third shape that forgets area() is a build error rather than an AttributeError in production. Java's closest approach to duck typing is Protocol-style structural checking in reverse: interfaces are declared by the implementer, not inferred at the use site.

Accessors are named after the component with no get prefix, so it is employee.name() rather than getName(). Records are always final and their components always immutable, so there is no mutable variant to choose — a mutable data holder is an ordinary class. You can add methods, as here, and a compact constructor for validation; you cannot add extra instance fields, which is the constraint that makes the generated methods trustworthy. Since Java 16 this has become the default way to model data, and it is why so much modern Java looks less verbose than its reputation.

Two Java advantages follow from it being built in. A variable of type Status can only ever hold ACTIVE, CLOSED or null, so a whole class of "somebody passed the string" bug is unrepresentable; and a switch over an enum is checked for exhaustiveness, so adding a third member turns every switch that has not been updated into a build failure. That last property is the single best reason to prefer an enum to a set of constants, and it has no Python equivalent — a match over Status that misses a member simply falls through. Comparison uses ==, matching Python's is, because enum members really are singletons.

The Python column is the same idea without enforcement. Card | Cash is a type alias a checker may consult, but nothing prevents a fourth class from appearing, so the fall-through return "unknown" has to stay. In Java, adding record Cheque(...) implements Payment means editing the permits clause and then finding that every switch over Payment stops compiling until it handles the new case — the compiler hands you the list of places to change. This combination of sealed types, records and pattern switches is how modern Java expresses what a functional language would call an algebraic data type.

The binding is scoped to exactly where the test is known to have succeeded, which is cleverer than it looks: inside the if body, and also after an early return in the negative branch, so if (!(value instanceof String text)) return ""; leaves text usable below. The pattern is what makes the older, error-prone shape — test, then cast to a type you retyped by hand — obsolete. Note that 21 arrives as an Integer rather than an int, because Object can only hold a reference; that is autoboxing from the Types section doing its work.

The mechanics differ in one way that matters when you write them. A Python class pattern matches by keyword — Delivery(city="Oslo") — and literals in the pattern are themselves part of the match, so the first case tests the city without a guard. A Java record pattern is strictly positional and its components can only bind or nest, never compare, so an equality test has to move into a when clause. Patterns nest in both: case Shipment(Delivery(String city, int parcels), var stamp) is valid Java. There is still no destructuring outside a pattern context, so a plain assignment cannot take a record apart.

Since Java 21 you can write case null, and doing so is the only thing that changes the behaviour: without it, this method still throws on describe(null) even though default is right there. That asymmetry catches people, because every other construct in the language treats default as "everything else". The safest habit coming from Python is to assume a switch is null-hostile unless it says otherwise, and to write case null, default -> ... when you genuinely want them handled together.

The pay-off is visible in the loop. Java's enhanced for can declare String name because the element type is guaranteed, so calling toUpperCase needs no check; the Python loop has to defend itself, or trust that nothing like the append(42) above ever happened anywhere in the codebase. This is also why Java collections need no equivalent of the isinstance filtering you see in defensive Python — the compiler already did it, once, at the boundary.

The difference is again what happens with the wrong type. number.get() is an Integer to the Java compiler, so assigning it to a String is a build failure, and the call to toUpperCase on the other box is checked the same way. In Python both are run-time events. Note the empty diamond in new Box<>("hello"): the compiler infers the argument from the declared variable, which is why generic Java is much less noisy to write than to read.

Both columns print that the two containers have the same class, for the same underlying reason: neither runtime records what the container is supposed to hold. What Java gets in exchange for erasure is a compile-time guarantee Python has no equivalent of; what it loses is everything reflective. You cannot ask an object what its type argument was, you cannot write instanceof List<String>, you cannot create an array of a type parameter, and a class cannot implement both Comparable<Foo> and Comparable<Bar>. When a library really needs the type at run time it asks you to hand it over as a Class<T> argument, which is why so many Java APIs take a SomeType.class parameter that looks redundant.

The reason invariance is right is worth holding on to: if a List<Integer> could be used as a List<Number>, somebody could add a Double to it, and the original list's element type would be a lie. The wildcard ? extends Number says "some specific subtype of Number, I do not know which", which makes reading safe and writing impossible — you cannot add to it, which is exactly the guarantee needed. Its mirror image, ? super Integer, allows writing and not reading. The mnemonic the Java world uses is PECS: producer extends, consumer super. (The first line of output differs only because total is declared to return double, so a sum of integers prints as 6.0 where Python's sum keeps it an int.) This is the part of generics that feels alien coming from Python, and it exists entirely to preserve the guarantee erasure cannot enforce at run time.

Java has no else clause on a try. Catching several types at once is catch (NumberFormatException | ArithmeticException problem), the equivalent of Python's tuple of exception classes. The habit worth breaking early is the bare except: — its Java spelling, catch (Exception problem), is just as broad and just as frowned upon, and its wider cousin catch (Throwable ...) also swallows OutOfMemoryError. Note too that Java exceptions carry a stack trace you print with problem.printStackTrace(), and that getMessage() may legitimately return null.

The commented-out method is the whole point: it is a build failure, not a warning. The upside is that a signature tells you what can go wrong, and a failure mode cannot be forgotten silently — the "we never handled that error path" bug is unrepresentable for checked types. The downside is real too, and opinion is genuinely divided within the Java world: checked exceptions do not compose with lambdas at all, and the pressure to keep signatures clean drives the anti-pattern catch (IOException e) { }, which is strictly worse than never having declared anything. Modern APIs and every recent JVM language lean unchecked, so most new code you write will throw RuntimeException subclasses — but the standard library's I/O, reflection and concurrency APIs are checked and always will be.

The resource is declared inside the try parentheses, and several may be declared there separated by semicolons — they are closed in reverse order, as nested with statements are. The one place Java is less capable is that close() cannot inspect or suppress the exception on the way out, where Python's __exit__ receives it and can return true to swallow it; an exception thrown by close() itself is instead attached to the original as a suppressed exception. Anything with a close method in the standard library already implements this interface, so files, sockets and database connections all work with it.

Extending RuntimeException, as here, gives you Python's behaviour: callers may catch it and are never obliged to. Extending Exception makes it checked, which puts throws InsufficientFunds in the signature of withdraw and every method above it. The usual guidance is to extend RuntimeException for programming errors and conditions a caller cannot sensibly recover from, and Exception only when the caller genuinely has a decision to make. Also note throw versus throws: the first raises, the second declares — a one-letter difference that is a compile error rather than a subtle bug, thankfully.

Because Optional is a real object rather than a special form, the emptiness is handled by chaining rather than by an if: map applies a function only when a value is present, and orElse supplies the fallback. ifPresent, filter and orElseThrow round it out. Two cautions from the Java community's own experience with it: optional.get() without checking is just null with extra steps, and Optional is meant for return types — using it for fields or parameters is widely considered a mistake, since it adds an allocation and a second kind of absence to every access.

So the parameter type here is IntUnaryOperator, and calling it means calling that interface's method, applyAsInt. The standard library supplies a couple of dozen of these in java.util.function: Function<T, R> (call it with apply), Predicate<T> (test), Consumer<T> (accept), Supplier<T> (get), plus primitive-specialized variants like the one above that exist purely to avoid boxing. Learning which name to declare is most of the friction in coming from Python; after that, lambdas behave as you expect, except that any local variable they capture must be final or never reassigned.

Read the two and note the order flips — a comprehension states the output expression first and the filter last, a stream applies its stages top to bottom. Streams are lazy, so nothing runs until toList(), and single-use: a stream cannot be traversed twice, which is why the sum on the last line opens a fresh one. The mapToInt step is not decoration — Stream<Integer> has no sum(), because summing boxed values is a different (and much slower) operation from summing an IntStream. For a simple loop over a collection, an enhanced for is still the more readable choice in Java; streams earn their keep when the pipeline is several stages long or ends in a non-trivial collector.

Both sorts are stable, so equal keys keep their original order — which is what puts Ada before Alan in the first line of output despite neither being compared on its name. The comparator style composes in a way key= does not: .reversed() flips the whole comparison, and Comparator.comparing(Employee::department).thenComparing(Employee::name) expresses a multi-key sort that Python spells with a tuple key. Note also that names.stream().sorted() returns a new list, while Collections.sort(list) and list.sort(comparator) sort in place, the way list.sort() does in Python.

There are four forms and it is worth recognizing them: String::toUpperCase (an instance method used as a one-argument function), Integer::parseInt (a static method), employee::name (a method bound to one particular object), and ArrayList::new (a constructor, which Python spells as just the class name). The double colon is the only new syntax; everything else follows from the functional-interface rules. Method references are the most common reason well-written modern Java reads more compactly than its reputation suggests.

The three-argument form used here is worth learning rather than the short one. Collectors.groupingBy(classifier) alone returns a HashMap, whose iteration order is unspecified — so the printed output can differ between runs, which is why TreeMap::new is passed to get sorted keys, the same job the sorted(grouped) call does on the Python side. The third argument is the downstream collector, and swapping it is where the power is: Collectors.counting() gives a frequency table, Collectors.mapping(String::length, toList()) transforms while grouping, and Collectors.partitioningBy(predicate) splits into just two buckets.

For anyone arriving from data work this is the headline. The Python pattern of reaching for multiprocessing to get around the GIL — paying for process startup, and for pickling every argument and result across a pipe — has no counterpart here; threads share one heap, so passing a large array to a worker costs a reference. That is also why the JVM is the substrate for Spark, Flink and Kafka. The bill arrives in the next row: with real parallelism, every piece of shared mutable state is your problem, and Python's habit of assuming a coarse-grained lock is protecting you does not transfer.

The Python version is less safe than its reputation suggests: the GIL guarantees that a single bytecode is atomic, not that total += 1 is, so the explicit lock is doing real work here rather than satisfying a formality. Java simply has no ambient lock to lull you, and it adds a second hazard Python does not have — visibility. Without synchronized or volatile, one thread's write may never become visible to another at all, because each core may keep its own cached copy; a loop polling an unsynchronized flag can spin forever on a value that was changed long ago. For a plain counter, AtomicInteger is both faster and harder to get wrong than a lock. The Java column cannot run on this page: the browser's sandbox (Compiler Explorer) allows a program only one thread beyond main, so the fourth worker fails to start.

The names line up almost too neatly — submit is submit, and future.result() is future.get(). Two Java details to keep in mind. A pool must be shut down or its threads keep the JVM alive after main returns, which is what the finally block is for; since Java 19 ExecutorService is AutoCloseable, so try (var pool = ...) does it for you the way Python's with does. And an exception inside the task does not escape at submit — it is stored and rethrown, wrapped in an ExecutionException, when you call get(), so a future whose result nobody asks for can swallow a failure entirely.

That is the whole pitch, and it is aimed squarely at the problem Python calls "function colour". A Java library written in 2005 against blocking sockets becomes scalable on virtual threads with no rewrite, because the blocking call itself was taught to yield; in Python, one synchronous call anywhere in an async stack blocks the entire event loop, so the ecosystem had to be duplicated. The cost is that virtual threads help only with blocking, not with CPU work, and that they interact badly with synchronized in older JDKs. The Java column cannot run on this page: starting even one virtual thread needs two operating-system threads — a carrier and an unblocker — and the browser's sandbox allows only one beyond main.

The older API you will still meet — File, FileReader, BufferedReader, a loop and a close() — predates this one and is worth avoiding in new code. Note that readString and readAllLines pull the whole file into memory, exactly as read_text does; the streaming equivalent of iterating a Python file handle is Files.lines(path), which returns a stream and should be closed with try-with-resources. Every one of these methods throws the checked IOException, which is why main declares throws IOException — the most common way a small program meets the checked-exception rule.

The third and fourth lines show the pair you actually need day to day: println appends a newline, print does not, matching print() and sys.stdout.write(). There is also System.out.printf for format strings. One behavioural difference to know when your log lines come out interleaved oddly: System.err is unbuffered while System.out is line-buffered, the same asymmetry Python has, and System.out.flush() is the fix. In a real application neither stream is used directly — logging goes through SLF4J or java.util.logging, in the way Python code uses the logging module rather than print. One thing to know about this page in particular: the Run button below the Java column reports standard output only, so the System.err line runs but does not appear there, while the Python cell — whose runner folds both streams into one buffer — shows all three. Run the two columns in a terminal and redirect one stream to see the real difference.

The trap that catches everyone once is mixing them: nextInt() consumes the number but leaves the newline behind, so the next nextLine() returns an empty string. Reading everything as lines and parsing yourself avoids it entirely. For large input, BufferedReader wrapped around an InputStreamReader is substantially faster than Scanner, which matters in competitive programming and almost nowhere else. Neither column can run on this page, because the sandboxes that execute these examples supply no standard input.

That is why there is no equivalent of Python's import-time side effects, no circular-import problem, and no cost to an unused import beyond clutter. Everything in the java.lang package — String, Math, Integer, System, Thread — is imported implicitly, which is why Math.floor above needs no line at the top. Java imports a single class per statement rather than a module: import java.util.List;, not import java.util. The wildcard form import java.util.*; exists and most style guides discourage it, since it makes the origin of a name invisible and can break when a library adds a class whose name collides.

The reverse-domain convention (com.example.analytics) exists because package names are the only namespace protecting one library's Reports from another's. The consequences for how code is laid out are large: one public type per file means a Java codebase has many more files than the equivalent Python one, and a class cannot be moved between packages without editing its first line and every import that names it — which is why every IDE has a dedicated refactoring for it. Both columns here are illustrative; the layout is the point and there is nothing to execute.

So there is nothing to activate and no way to be in the wrong environment, and two projects on one machine can use different versions of the same library without noticing each other. The coordinates are always three parts — group, artifact, version — and they are globally unique, so pip install requests's ambiguity about which package that is does not arise. What you gain in reproducibility you pay for in ceremony: a Maven pom.xml is XML and long, Gradle trades that for a build script that is a real program, and neither is as quick to start as a pip install. Both columns describe shell and configuration, so there is nothing to run.

Backward compatibility is the JVM's strongest selling point and the reason so much old Java is still in production: a jar compiled in 2010 will very likely still run today, which is not a claim the Python 2-to-3 transition can make. The habit you will miss is the one in the last block. jshell genuinely works, but the Java workflow is edit-compile-run with the IDE compiling continuously in the background, and the exploratory loop moves into unit tests and the debugger instead. Expect the feedback cycle to be seconds rather than instant, and expect the compiler to catch things you would previously have found by poking. Both columns are shell transcripts, so there is nothing to execute here.