Perl.CodeCompared.To/Java

This is the starkest contrast between the two languages, visible from the very first line. Perl runs a script top to bottom with no ceremony at all — say "Hello, World!"; is a complete, valid program. Java requires every single line of code, even the simplest one, to live inside a class, and that class must expose an entry point method with the exact signature public static void main(String[] args). There is no such thing as top-level code in Java; the class-and-main wrapper is mandatory, not optional boilerplate that can be trimmed away.

Perl is purely interpreted — there is no separate artifact produced before running a script, and perl -c only checks syntax without executing anything. Java has always required a distinct compile step producing JVM bytecode (a .class file) before java can run it; the single-file source-launcher shortcut added in JDK 11 (java Hello.java) hides that step for quick scripts, but the compilation still happens in memory every time — it is a convenience, not proof that Java became interpreted. A Perl programmer's instinct to just "run the file" mostly transfers with the single-file launcher, but production Java code is always compiled ahead of time into .class or .jar files.

Java uses the familiar C-style comment syntax — // for a single line, /* ... */ for a genuine multi-line block, and the special /** ... */ Javadoc form that the javadoc tool consumes to generate browsable HTML API documentation. This is a real improvement over Perl, which has no true multi-line comment construct at all — Perl programmers either stack consecutive # lines or reach for the Pod =begin/=end markers borrowed from documentation tooling, and Perl has nothing equivalent to Javadoc's tight integration between comments and generated documentation.

Java's System.out.println() is the direct equivalent of Perl's say — both append a trailing newline automatically, and both accept a bare number with no explicit stringification required. Suppressing the newline needs System.out.print(), the mirror of Perl's print (no newline) versus say (with newline) being two separate functions. The System.out prefix itself is worth noting: it is a static field on the System class holding a PrintStream object, so every call is a genuine method call on an object, not a standalone global function the way Perl's print/say are.

Perl marks the shape of a variable with a leading sigil — $ for a scalar, @ for an array, % for a hash — and the value can hold anything of that shape without ever declaring a type. Java instead requires every variable to carry an explicit compile-time type declaration (String, List<String>, Map<String, Object>): the type is written once at declaration and checked by the compiler forever after, rather than inferred dynamically from whatever value happens to be assigned. This is the single biggest theme running through this entire cheatsheet — nearly every section below returns to some consequence of Java's mandatory static typing.

This is the recurring theme a Perl programmer will notice throughout every section of this cheatsheet: Perl catches type mismatches, if at all, at runtime — often only as a warning, and only if that exact line of code actually executes during a particular run. Java catches them at compile time, before the program runs at all, because javac statically verifies that every expression's type matches what its context expects. The tradeoff is real: Java demands upfront ceremony (every variable, parameter, and return value needs a declared type) in exchange for a whole category of bugs — passing the wrong shape of data — being caught long before deployment rather than discovered by a user in production.

The var keyword (Java 10+) lets the compiler infer a local variable's type from its initializer, saving some of the declaration verbosity a Perl programmer might expect Java to always demand. It is important not to mistake this for dynamic typing, though: the type is still determined once, at compile time, from the right-hand side of the assignment, and it is then fixed for that variable's entire lifetime — attempting to later assign a String to a var that was inferred as int is still a compile error. var is also restricted to local variables only; it cannot be used for fields, method parameters, or return types.

Java's checked exceptions are really just the compile step extending its type-checking discipline to error handling: a method that can throw a checked exception must say so in its signature with throws, and every caller must either handle it or declare it too, all verified before the program runs. Perl has nothing resembling this — a subroutine can die for any reason at any time with zero declaration anywhere, and the only way to discover an unhandled error path is to actually execute it. This ceremony is the single most surprising recurring "gotcha" a Perl programmer hits throughout Java code: forgetting a throws clause or a try/catch block is a compile error, not a runtime crash.

Perl's use constant pragma enforces immutability at compile time — reassigning one is a compile error, matching Java's guarantee here fairly closely. The Java final keyword on a field makes the binding permanently unassignable after its first value, verified by the compiler; pairing it with static makes it a single shared value belonging to the class itself rather than to any particular instance, which is the idiomatic way to declare a constant in Java. As with JavaScript's const, final only locks the reference itself — a final List<String> still permits adding elements to the list it points to, since the list's contents are a separate concern from the variable binding.

This is a place where Java's static typing eliminates an entire category of Perl subtlety rather than merely relocating it: Java has no concept of truthiness whatsoever. An if condition must be an expression of type boolean (or the boxed Boolean), full stop — there is no automatic coercion from String, int, or a reference into true or false, and passing a non-boolean expression to if is a compile error, not a runtime surprise. Reproducing Perl's "empty string or literal \"0\" is falsy" idiom in Java always requires writing out the exact boolean condition explicitly, as shown here.

Perl interpolates a bare $name directly inside a double-quoted string with no ceremony, and even embeds an arbitrary expression via the @{[ expression ]} trick. Java has no true string interpolation at all — the idiomatic approach is either plain + concatenation, which gets unwieldy fast, or String.format() with C-style %s/%d placeholders, which is closer in spirit to Perl's sprintf than to its interpolation. Java 21 introduced a string templates preview feature that would have closed this gap directly, but it was withdrawn before becoming a permanent language feature, so String.format() and concatenation remain the standard tools.

Perl's string operations are mostly standalone functions — length($text), uc($text), index($text, ...) — that take the string as an argument, and there is no built-in trim function at all (Perl trims with a manual regex substitution). Java's String is a genuine class with methods called directly on the object: text.length(), text.toUpperCase(), and — since Java 11 — text.strip() for Unicode-aware whitespace trimming, a built-in Perl still lacks. Reversing has no dedicated String method, since String is immutable in Java; the idiomatic approach wraps it in a mutable StringBuilder, which does have a .reverse() method, then converts back via toString() (implicit here in println).

Java's text blocks (Java 15+), delimited by triple double-quotes """, are a close match for Perl's squiggly heredoc <<~LABEL: both automatically strip the common leading indentation shared by every line, based on the position of the closing delimiter, so the source can be indented naturally to match the surrounding code. Text blocks do not interpolate variables directly the way Perl heredocs do, though — combining one with .formatted(...) (or String.format()) is the idiomatic way to substitute values in, mirroring Perl's heredoc interpolation with one extra method call.

This is one of the more comfortable corners of Java for a Perl programmer: both languages inherited the same C-style format-string mini-language, and the placeholders here — %-10s, %6.2f, %08X, %05d — are spelled identically in both. Java's System.out.printf() mirrors Perl's printf directly (prints immediately, no return value), while String.format() mirrors Perl's sprintf (returns the formatted string instead of printing it). The one gotcha: Java's %n is the portable newline placeholder — it produces the host platform's native line ending, unlike the literal \n Perl always uses.

Java's string.split(regex) mirrors Perl's split closely, including accepting a regular expression directly as the separator — though Java calls it as a method on the string, returning a plain String[] array, while Perl calls it as a standalone function returning a list. Joining reverses the calling convention: Java's String.join(separator, array) is a static method taking the separator first, while Perl's join($separator, @list) is also a standalone function with the separator first — genuinely the same shape here, unlike the array-method style JavaScript and Ruby both use for joining.

Perl string scalars are always mutable — .= appends in place with no restriction. Java strings are immutable by design: every operation that looks like mutation, including +=, actually creates an entirely new String object and rebinds the variable to it. This has real performance implications in a loop that builds up a string incrementally — repeated += concatenation allocates a new string on every iteration — so the idiomatic fix is the mutable StringBuilder class, appending to it in a loop and calling .toString() (implicit in println here) once at the end.

Perl's scalar draws no distinction between integer and floating-point values at the type level — one scalar can hold either, and arithmetic between them just works. Java instead has a family of distinct numeric primitive types with fixed bit widths: int (32-bit), long (64-bit, needs an L suffix on literals that exceed int's range), float (32-bit decimal), and double (64-bit decimal, the default for a literal like 3.14). Choosing the wrong one is a genuine compile-time concern in Java — assigning a value too large for int to an int variable is a compile error, not a silent overflow or an automatic promotion the way Perl (and JavaScript) handle numbers past their safe integer range.

This is a wrinkle with no Perl equivalent at all: because Java primitives like int are not objects, they cannot be used as a generic type parameter (List<int> is illegal) or stored in a collection directly. Every primitive type has a corresponding boxed wrapper class — int/Integer, double/Double, boolean/Boolean — and the compiler automatically converts between them (autoboxing and auto-unboxing) so the code above never needs to write Integer.valueOf() explicitly. Perl has nothing resembling this distinction since every scalar is already usable anywhere, with no separate "primitive" representation to convert away from.

This is a genuine mechanical difference worth calling out: Perl's / always performs floating-point division regardless of operand types, so getting a truncated integer result needs an explicit int(...) call. Java's / instead branches on the operand types at compile time — dividing two int values truncates toward zero automatically, while dividing with at least one double operand produces a floating-point result — so 10 / 3 and 10.0 / 3 genuinely mean different things in Java. The two languages also disagree on the sign of % with a negative operand: Perl's modulo takes the sign of the right operand (-7 % 3 is 2), while Java's % is a true C-style remainder that takes the sign of the left operand (-7 % 3 is -1) — a real trap when porting wraparound-index logic without adjustment.

Both languages check parity and sign with inline comparison expressions — there is no dedicated even?-style predicate method in either. Perl's abs is a standalone built-in function, while Java groups nearly all of its numeric functions as static methods on the Math class — Math.abs(), Math.floor(), Math.max() — rather than exposing them as free-floating global functions. Java has no native integer range syntax matching Perl's 0..2; the classic C-style three-part for loop, which Java kept exactly as C and Perl both spell it, is the idiomatic replacement for a fixed count of iterations.

Perl coerces a numeric-looking string to a number implicitly the moment it appears in numeric context — "42" + 0 just works. Java has no implicit string-to-number coercion at all: "42" + 0 in Java is actually string concatenation (Java overloads + for strings the same way JavaScript does), producing the string "420", not the number 42. Every conversion in Java must be explicit — Integer.parseInt(), Double.parseDouble() — and going the other direction, Integer.parseInt(string, radix) takes an explicit base argument just like Perl's hex() is really shorthand for base 16, while Integer.toHexString() replaces Perl's sprintf("%x", ...).

This is a genuine structural difference, not just a syntax gap: a Perl @array is always dynamically sized — push, pop, shift, and unshift all grow or shrink it freely at runtime. A Java array's length is fixed permanently at the moment it is created; there is no way to grow one, and attempting to write past its bounds throws an ArrayIndexOutOfBoundsException rather than silently extending the array the way Perl would. Also note the length check itself: Java's array.length is a plain field access (no parentheses), while Perl's equivalent is the function call scalar(@numbers). For anything resembling Perl's freely growing array, Java's java.util.List/ArrayList (next concept) is the tool to reach for instead of a raw array.

A Java ArrayList is the genuinely dynamic counterpart to Perl's @array — it grows and shrinks freely, backed internally by a plain array that gets reallocated and copied as needed, entirely hidden from the caller. The method vocabulary is less friendly than JavaScript's exact-name match with Perl, though: .add(value) replaces both push and (with an index argument) unshift, and .remove(index) replaces both pop (pass size() - 1) and shift (pass 0) — there is no single dedicated method spelled exactly like Perl's four array-mutation primitives, so the index argument does the work of distinguishing "front" from "back."

Perl supports negative indexing directly ($numbers[-1] for the last element), one of its most convenient array features. Java has absolutely no negative-indexing support anywhere — .get(-1) throws an IndexOutOfBoundsException immediately rather than silently returning something unexpected, so reaching the last element always needs the explicit size() - 1 arithmetic shown here. Slicing has the same inclusive/exclusive mismatch seen elsewhere in this comparison: Perl's @numbers[1..3] range slice is inclusive on both ends, while Java's .subList(1, 4) is half-open — the stop index is exclusive — so the equivalent three-element slice needs 4, not 3, as the stop argument.

Perl's sort defaults to string comparison — sorting numbers correctly requires the explicit { $a <=> $b } comparator block, a common beginner trap. Java's Collections.sort() avoids this trap for a List<Integer> specifically, since Integer implements Comparable with genuine numeric ordering built in — no comparator needed for the common case, though a custom Comparator can still be supplied as a second argument for other orderings. The bigger difference is mutability: Perl's sort and reverse both return new lists, leaving the original untouched, while Collections.sort() and Collections.reverse() both mutate the list argument in place and return nothing — copying first (new ArrayList<>(numbers)) is necessary to preserve the original.

Perl's map and grep are standalone functions taking a block and a list directly; summing needs the CPAN-distributed core module List::Util's sum0. Java's Streams API (Java 8+) covers the same three operations as chained method calls on a .stream() view of the collection: .map() transforms, .filter() replaces grep under a different name, and .reduce() covers summing (and any other fold) with no import needed beyond the collector for gathering results back into a List. The .collect(Collectors.toList()) step is real ceremony Perl has no equivalent for — a Java stream is lazy and one-shot, so it must be explicitly materialized back into a concrete collection before it can be reused or printed directly.

Just as with arrays, Perl declares a hash with the % sigil but reads an individual value with $scores{alice}, while Java requires an explicit generic type declaration — Map<String, Integer> — spelling out both the key type and the value type up front, something dynamically typed Perl has no concept of at all. Map.of(...) (Java 9+) builds a small, genuinely immutable map from alternating key-value arguments — a reasonable match for a Perl hash literal, though .get("alice") is a method call rather than the bracket-and-sigil syntax Perl uses, and counting entries needs the explicit .size() method rather than a standalone keys function.

Map.of(...) from the previous example is genuinely immutable — attempting .put() on it throws UnsupportedOperationException — so ordinary mutable key-value storage needs HashMap instead, constructed with new HashMap<>() and built up with repeated .put() calls. Perl's exists checks key presence without triggering autovivification; Java's .containsKey() plays the same role directly. Perl's // defined-or default has a close match in .getOrDefault(key, fallback), a single method call rather than a separate operator, which returns the fallback value immediately if the key is absent rather than returning null and requiring a follow-up check.

Perl's keys and values functions have direct equivalents in Java's Map interface, .keySet() and .values(), though called as methods rather than as free functions. Where a Perl programmer loops with for my $key (keys %hash) and then looks up $hash{$key} inside the loop, Java's .entrySet() yields both the key and value together as a Map.Entry object in one step, read out with .getKey()/.getValue() — no separate lookup needed. Ordinary HashMap has no guaranteed iteration order at all (unlike a plain Perl hash, which is merely randomized for security, not fully unordered); reaching for TreeMap instead, as shown here, is the idiomatic way to get keys back in sorted order automatically rather than calling sort separately.

Perl hashes silently coerce every key to a string, so a Perl programmer already knows to be careful using a reference as a hash key (it stringifies to its memory address, not something useful to compare later). Java's Map keys are not coerced at all — the key type is declared explicitly as a generic parameter, and an Integer key genuinely stays an Integer, compared by value via its .equals()/.hashCode() implementation, never silently turned into a string. The .merge(key, 1, Integer::sum) call is also worth a note on its own: it is Java's built-in equivalent of Perl's autovivifying $counts{key}++ — insert the value if absent, otherwise combine it with the existing value using the supplied function — collapsing what would otherwise be an explicit containsKey check into one call.

This is the single biggest conceptual difference between the two languages, and Java's static type system leaves absolutely no room for it — every expression in Java has one fixed, statically known type, determined entirely by its declaration, never by the context surrounding where it is used. In Perl, the exact same expression (@animals, or a parenthesized list) evaluates differently depending on whether it appears in a context that wants one value (scalar context) or many (list context) — assigning an array to a scalar silently gives you its length, but assigning a literal list (1, 2, 3) to a scalar gives you its last element, not its count. Java has no such duality: getting a count always means calling .size() or reading .length explicitly, and there is no assignment target that could ever reinterpret a List as anything other than the same List.

Perl's wantarray lets a subroutine inspect the context it was called in and return a fundamentally different value — a different shape entirely — depending on whether the caller wants a list, a scalar, or nothing (void context). Java has no equivalent mechanism whatsoever, and its type system actively forbids the idea: a method's return type is declared once in its signature and is permanently fixed, so a method returning List<Integer> can never instead return a single String based on caller context. It is entirely up to the caller to decide what to do with the one, statically typed value a Java method returns.

Perl offers several implicit ways to coerce an array into its count — numeric context, string concatenation, or the explicit scalar() function all work interchangeably. Java offers no such shortcuts at all: concatenating a List directly into a string calls its .toString() method, printing something like [10, 20, 30, 40], not its size — .size() must always be called out explicitly, with no context-sensitive alternative anywhere in the language.

Java spells the middle branch as two full words, else if, rather than Perl's single contracted keyword elsif — technically Java has no elseif keyword at all; it is simply an if statement nested as the body of an else, which happens to read the same way. The condition itself must be a genuine boolean expression in Java (see the truthiness concept above), where Perl accepts any value at all and applies its own truthiness rules — otherwise the syntax and control flow here are close to identical between the two languages.

This is a real loss for a Perl programmer: Java has neither an unless keyword nor a postfix statement-modifier form for if at all — Ruby borrowed both of these directly from Perl, but Java never adopted either. Every conditional guard must be written as a full if (...) { } block, even for the simplest one-line guard clause that Perl would express as statement unless condition;. Java does have a conditional (ternary) expression (condition ? valueIfTrue : valueIfFalse), but it produces a value for assignment rather than gating a statement, so it is not a substitute for the postfix-modifier idiom.

Perl's numeric range 1..5 has no single built-in Java equivalent — the classic C-style three-part for loop is the standard replacement, since Java has no range literal syntax at all. Perl's character range "a".."e" also has no direct Java equivalent, but Java's primitive char type is itself an integer type under the hood, so a for loop over char values with letter++ works naturally with ordinary arithmetic comparison — arguably a smaller gap than the one Python or JavaScript have here, since Java's char arithmetic requires no explicit code-point conversion functions at all.

Both languages have a while loop with the same semantics, and both keep C-style ++/-- increment and decrement operators (Ruby dropped these, but Perl and Java both kept them). Java has no until keyword at all (Ruby has one, borrowed from Perl, but Java never adopted it) — "loop while some condition is false" must always be written as a negated while, exactly the workaround JavaScript needs for the same gap.

Perl once had an experimental given/when construct but removed it due to design problems with smart matching, leaving Perl programmers to fake it with a for ($topic) { if (...) { ...; last } } loop. Java's modern switch expression (Java 14+, using -> rather than the old colon-and-break statement form) is a genuine, permanent, and considerably safer equivalent: there is no fall-through by default, no break to remember, and comma-separated case labels (case "east", "west" ->) group several values under one branch cleanly — closer in spirit and safety to Perl's workaround than the traditional C-style switch statement most other languages still default to.

Perl subroutines receive all arguments bundled into the single array @_ and must manually unpack them with my ($number) = @_; — there is no way to name parameters in the signature itself in the widely used, portable syntax, and no way to declare what type each argument must be. Java methods declare every parameter with both a name and a mandatory type directly in the signature (static int square(int number)), and the return type is likewise mandatory and fixed (int, String) — so there is no unpacking step at all, but every method signature is considerably more ceremony-laden than Perl's bare sub name { ... }. A Java method must also declare an explicit return statement matching its declared return type; there is no implicit "last expression is the return value" convention the way Ruby has.

Perl's anonymous subroutine (sub { ... }) needs the explicit -> arrow to be called ($square->(7)), since a code reference is just another kind of reference requiring dereferencing. Java's lambda expression syntax (Java 8+) is considerably terser for the common case of a single-expression callback — number -> number * number needs no return keyword, no braces, and no explicit type declaration for the parameter (it is inferred from the target functional interface, here Function<Integer, Integer>) — but calling it requires the interface's single abstract method, .apply() in this case, rather than a universal calling syntax. Lambda expressions are also the idiomatic way to write the transform passed to .map(), playing the same role as Perl's { $_ * 2 } block passed to map.

Perl has no default-parameter syntax in the subroutine signature either — the idiomatic approach is unpacking positionally from @_ and then using //= (defined-or assignment) to fill in a default for any argument left undef. Java goes further: it has no default-parameter syntax whatsoever, not even inside the method body, because every method's parameter list is part of its fixed, compile-time signature. The idiomatic Java replacement is method overloading — declaring a second method with the same name but a shorter parameter list, which simply delegates to the fuller version — a solution that scales poorly once more than one or two optional parameters are involved, unlike Perl's single flexible subroutine.

Neither language has true keyword arguments as a core language feature the way Python does. Perl simulates them by unpacking a flat list into a hash (my (%args) = @_;), reading each named value out afterward. Java has no equivalent unpacking trick at all — passing a single low-ceremony record (see the Records section below) as one parameter is the closest idiomatic substitute, giving named, typed fields at the call site (parameters.name()) instead of Perl's hash-key lookups, at the cost of needing to construct the record positionally (new UserParameters("Alice", 30, "Paris")) rather than with Perl's order-independent name => "Alice" style.

This is the most consequential structural difference between the two languages, after context sensitivity — and it happens to be one where Java is closer to a language a Perl programmer might not expect: C, not Ruby or JavaScript, is the odd one out here, since C requires explicit pointer syntax the way Perl requires explicit reference syntax. Perl distinguishes plain values from references explicitly: creating one needs the \ operator, and reading through one needs either the -> arrow or a sigil-based dereference like @$array_ref — the reference-ness of a variable is always visible in the syntax used to touch it. Java has no separate reference type or reference-creation operator at all: every non-primitive value (an object, an array, a List) is a reference by nature, assignment never copies one, and reading or writing through it uses the exact same dot or bracket syntax as any other value — there is nothing that visually marks a variable as "a reference" the way Perl's sigils and arrows do. In this respect Java's object semantics resemble Perl's own reference semantics far more than Perl's plain scalar-copy semantics.

This is where Perl's explicitness becomes a real safety feature: assigning one Perl array to another with @copy = @original always copies every element, and only an explicit reference assignment shares the underlying storage. Java has no plain-value assignment mode for a List or any other object type at all — List<Integer> assigned = original always shares the same underlying list, full stop, since there is no non-reference way to hold one in the first place. A genuine copy requires an explicit operation, most commonly the copy constructor shown here (new ArrayList<>(original)), and forgetting this is one of the most common sources of action-at-a-distance bugs for a Perl programmer arriving in Java, exactly the same trap JavaScript sets for arrays and objects.

Perl's undef behaves gracefully in most contexts — it stringifies to an empty string (with a warning), and numeric operations on it quietly treat it as zero. Java's null is far less forgiving: it is a legitimate value for any object-reference type, but calling any method on a null reference — even something as simple as .length() — throws a NullPointerException immediately and crashes the program if uncaught. This is such a pervasive category of Java bug that it has its own long history of mitigation techniques (the Optional<T> type, Objects.requireNonNullElse(), and simple defensive != null checks like the one here) — a Perl programmer's instinct to check defined() before using a value maps directly onto checking != null in Java, but the consequence of skipping the check is a hard crash rather than a warning.

This is a big ergonomics gap worth calling out plainly: Perl treats a regular expression as a genuine first-class literal syntax, delimited by forward slashes, matched directly against a string with the =~ binding operator — regex use is woven into the language itself. Java has no regex literal syntax at all; every pattern is an ordinary string that must be explicitly compiled with Pattern.compile() into a Pattern object, then matched against text through a separate Matcher object obtained via .matcher(), with .find() to search and .group(n) to read a captured group — four extra layers of object machinery, plus the double-backslash escaping every pattern needs since it lives inside an ordinary Java string. This verbosity is one of the most immediately noticeable differences a Perl programmer hits moving to Java.

Perl's s/pattern/replacement/g operator performs the substitution in place on a copy (the (my $replaced = $text) =~ s/.../ idiom copies first, then substitutes destructively). Java's text.replaceAll(regex, replacement) is a pure method that always returns a new string, leaving the original untouched — no destructive substitution operator exists in Java, matching the language's immutable-string design overall. Counting matches has no dedicated syntax in Java comparable to Perl's clever my $count = () = $text =~ /pattern/g; list-context assignment trick; the idiomatic Java approach falls back to manually looping over matcher.find() and incrementing a counter, considerably more verbose than either language's one-liner alternatives.

Named capture groups are spelled identically in both languages — (?<name>...) — since Java's regex engine directly copied Perl's named-capture syntax rather than inventing its own, one of the closest syntax matches anywhere in this comparison. The difference is entirely in how the captured value is retrieved: Perl populates the special hash %+, accessed as $+{year}, while Java requires calling matcher.group("year") as a method — still through the same Pattern/Matcher machinery as every other Java regex operation, with none of Perl's direct-binding-operator convenience.

This is where a Perl programmer will feel real envy — a huge step up. Perl OOP is built manually from two separate primitives: a package to hold the namespace, and bless to associate a plain hash reference with that package so it is recognizable as an object — every constructor is hand-written, and there is no compiler enforcement of what fields an "object" of a given class is even supposed to have. Java has a genuinely mandatory, fully-featured native class system: class Animal { ... } declares real fields with real declared types, a real constructor with a fixed signature the compiler checks at every call site, and real encapsulation via access modifiers (private here) — none of it hand-rolled, all of it enforced by the compiler before the program ever runs.

Perl has no built-in accessor generation and no true privacy at all — the accessor methods shown here are entirely hand-written, and even calling $person->{age} directly, bypassing the accessor completely, works fine since a leading underscore or any other privacy signal is purely a naming convention that nothing in the language enforces. Java's private keyword on the name and age fields is a genuine, compiler-enforced access restriction — attempting person.age from outside the Person class is a hard compile error, not merely bad manners. This is a real step up in encapsulation strength for a Perl programmer used to every object's internals always being reachable if someone really wants to reach them.

Perl declares inheritance by populating the special array @ISA with parent package names (or, in modern Perl, the more readable use parent 'Animal'; pragma) — a mechanism with no compiler involvement at all. Java uses the extends keyword directly in the class declaration, and a subclass constructor must explicitly call the parent constructor with super(...) as its first statement (the compiler inserts an implicit no-argument super() call only if the parent has a no-argument constructor available). Java's instanceof operator replaces Perl's isa method call for checking ancestry, and the @Override annotation — optional but strongly idiomatic — has no Perl equivalent: it asks the compiler to verify that speak genuinely overrides a parent method, catching a typo'd method name as a compile error rather than a silent no-op.

Java has no true operator-overloading protocol for a custom class, just like JavaScript — unlike Perl's use overload pragma, there is no way to make Java's built-in + operator invoke a method on a custom object; addition between two Money instances must be an explicit method call like .add() rather than total + other. Where the languages do align is stringification: overriding toString() (always annotated @Override by convention, since it is inherited from the universal base class Object) plays exactly the role Perl's '""' overload entry plays, and Java needs no separate pragma to opt in — System.out.println(total) calls toString() automatically wherever an object is coerced to a string.

This is a genuinely comparable pairing worth pausing on: Java's record (Java 16+) is the closest thing in this entire comparison to a lightweight Perl hash-based struct, and it is arguably the single least ceremony-heavy corner of the whole language. A one-line record declaration, record Point(int x, int y) {}, automatically generates a constructor, accessor methods named after the components (x() and y(), not the Java-conventional getX()), a working equals(), hashCode(), and a readable toString() — all four are hand-rolled or entirely absent for a plain Perl hash reference, which enforces no shape at all and generates nothing. All record components are implicitly final, making every record immutable and thread-safe by construction, a guarantee a plain Perl hash reference has no way to express.

Custom methods can be added inside a record body and have full access to its components as plain local variable names, no accessor call needed even from inside the record itself. Because every component is implicitly final, a method that "modifies" a record — translate here — must return a brand-new instance rather than mutating the existing one, exactly the immutable-update discipline a careful Perl programmer would otherwise have to enforce entirely by convention when building a similar pattern from a plain hash reference, with nothing stopping a less careful caller from mutating the hash directly instead.

Sealed classes (Java 17+) restrict which classes may extend or implement them — the permits clause names every allowed subtype — and combined with records, this gives Java a genuine algebraic-data-type story with compiler-verified exhaustiveness: if Shape can only ever be Circle or Rectangle, the switch expression above needs no default branch at all, because the compiler itself proves every case is handled. Perl has no equivalent whatsoever — duck typing means any package can inherit from any other at any time, so nothing can ever prove a dispatch table or if/elsif chain is exhaustive, and a missing case is only discovered when that exact code path runs (or never discovered at all).

die is Perl's throw; a bare eval { } block is the try-block equivalent of Java's try/catch. Java's error-handling ergonomics are a real improvement over Perl's global-variable-based approach: the caught exception object is bound directly to a local variable at the point of the catch clause (catch (RuntimeException error)), with no equivalent of Perl's easy-to-forget or easy-to-accidentally-clear $@ global to check manually. Java additionally distinguishes RuntimeException (unchecked, used here) from checked exceptions like IOException — the next concept covers exactly why that distinction matters and why it will surprise a Perl programmer more than anything else in this section.

This is the single biggest error-handling surprise for a Perl programmer moving to Java. Perl subroutines can die for any reason at any time, and nothing in the language requires — or even allows — declaring which failures a subroutine might raise; discovering an unhandled die means actually hitting it at runtime. Java's checked exceptions (like IOException here) are verified by the compiler itself: any method that can throw one must declare it with throws in its signature, and every caller must either catch it or declare it onward — omitting both is a compile error, not a runtime crash waiting to happen. Unchecked exceptions (subclasses of RuntimeException, as in the previous concept) opt out of this requirement entirely, which is why most everyday logic errors in Java use the unchecked family while I/O and other genuinely recoverable external failures use checked exceptions.

Perl can die with a blessed object instead of a plain string, letting the surrounding if branch on ref($error) && $error->isa("ValidationError") to distinguish error types — a manual pattern with no dedicated exception-class hierarchy backing it. Java's exception classes are designed to be subclassed directly: extends RuntimeException plus a super(message) call in the constructor produces a genuine exception type complete with a stack trace and full participation in Java's exception-matching machinery, and the catch (ValidationException error) clause matches by declared type natively — no isa-style runtime check needed, since the compiler and JVM both understand the type hierarchy directly.

Perl has no dedicated cleanup block syntax in the language core — guaranteeing cleanup code runs whether or not die was called requires either careful manual bookkeeping (saving $@ immediately, since a later operation can silently clear it) or a module like Try::Tiny or core Feature::Compat::Try's finally block. Java's try/catch/finally has a dedicated finally clause built directly into core syntax: code inside it always runs, whether the try block completed successfully, threw an exception that was caught, or even if the catch block itself returned or re-threw — no manual state-saving required, and no risk of a later statement silently clobbering error state the way Perl's $@ can be overwritten by an unrelated subsequent operation.

This is a concept with genuinely no Perl analog: Perl has no static type system whatsoever, so a single array or hash freely mixes values of any type with no declared constraint — there is nothing resembling a "type parameter" to even talk about. Java's generics, written with angle brackets (Box<T>, List<Integer>), let a class or method be written once and parameterized over whatever type its caller chooses, with the compiler verifying at every call site that the chosen type is used consistently — new Box<String>("hello") can never accidentally hold an Integer, because the compiler rejects that assignment before the program ever runs. Every one of Java's collection types (List<T>, Map<K, V>) is itself built on generics, which is why a type declaration like Map<String, Integer> appears throughout the Hashes section above.

Perl needs no special syntax to write a single subroutine that works on any type of value, since nothing about a Perl subroutine's parameters is ever type-constrained in the first place — genericity is simply the default, unremarked-upon behavior. Java has to earn the same flexibility explicitly through a generic method: the <T> before the return type introduces a type parameter scoped to that one method, letting firstElement work on a List<Integer> or a List<String> alike while the compiler still verifies, for each individual call, that the return type matches what the caller expects — genuine flexibility, but arrived at through explicit declaration rather than Perl's default absence of any type constraint to begin with.

Perl has no interface keyword at all — a "contract" like "this object must have an info method" exists purely as an unenforced convention, satisfied by duck typing: any object with a method of that name works, and nothing checks this formally or catches a missing method before runtime. Java's interface keyword declares a genuine, compiler-checked contract: a class declares implements Printable and the compiler refuses to compile it unless every abstract method (info() here) is actually implemented. Default methods (Java 8+, the printInfo() method here) let an interface provide a working method body that calls the abstract method a conforming class must supply — the closest Java equivalent to a Perl role or mixin, but with the method names and their required signatures verified ahead of time rather than discovered only when called.

A Java class may implement multiple interfaces at once, separated by commas — a formal, compiler-verified version of the ad hoc composition a Perl programmer gets simply by defining several methods on one package (or, more formally, using Role::Tiny or Moo/Moose roles from CPAN, which Java has no need of since the capability is built into the core language). If two implemented interfaces declared conflicting default methods with the same signature, Java would force the implementing class to override the method explicitly to resolve the ambiguity — a compile-time safeguard against silent conflicts that a Perl programmer composing behavior from multiple sources has no equivalent protection against. Java allows only single inheritance of classes (extends) but unlimited interface implementation (implements).

Perl opens a file handle with a three-argument open call and reads it line by line with the diamond operator <$file_handle> inside a while loop, closing it explicitly afterward. Java's modern java.nio.file.Files API reads every line into a List<String> in one call, with the file handle opened and closed entirely internally — no explicit close to remember, at the cost of loading the whole file into memory at once rather than streaming it line by line. Note also that main itself declares throws IOException here, propagating the checked exception up rather than catching it locally — a legitimate, common Java pattern for a small program willing to let an I/O failure simply crash with a stack trace. Both sides assume a data.txt file already exists on disk, so neither can run in the sandboxed backends used by this page.

Perl opens the file handle in write mode with the > mode string, prints directly to the handle, and closes it explicitly. Java's Files.writeString() collapses the open-write-close sequence into a single call that handles opening and closing the underlying file descriptor internally — there is no separate handle object for the caller to manage or remember to close, at the cost of always writing the entire content in one call rather than streaming it incrementally the way Perl's handle-based approach naturally allows.

Perl's @ARGV contains exactly and only the user-supplied command-line arguments, indexed from 0. Java's args parameter to main matches this precisely — it too contains only the user-supplied arguments with no extra leading entries for the executable path or script name, unlike Node.js's process.argv, which does carry those two extra entries. This is one of the more comfortable, low-friction corners of Java for a Perl programmer: the mental model transfers with no offset adjustment needed at all.

Perl's %ENV hash supports both reading and writing directly — assigning $ENV{MY_VAR} = "custom value" works immediately and is visible to any child process spawned afterward. Java's System.getenv() is read-only: it returns an immutable view of the current process's environment, and there is no way to modify the running JVM process's own environment variables at all from within Java code — setting an environment variable for a child process requires the separate ProcessBuilder.environment() API instead of a simple map assignment. Reading a missing variable returns null in Java rather than Perl's undef, but the defensive-check pattern is otherwise identical.

CPAN (the Comprehensive Perl Archive Network) predates Maven Central by roughly a decade and pioneered the idea of a central package repository with a dependency-declaration file — Perl's cpanfile plays a similar role to Maven's pom.xml or Gradle's build.gradle. The practical experience differs sharply, though: cpanm is a single, universally agreed-upon installer, while the Java ecosystem has two dominant, mutually incompatible build tools (Maven and Gradle), each with its own dependency-declaration syntax and its own way of resolving and downloading artifacts from Maven Central — a genuinely richer, more enterprise-oriented ecosystem than CPAN, but with more upfront tooling choice to make.

Reproducible installs are a more recent, optional addition to the Perl ecosystem: Carton, modeled explicitly on Ruby's Bundler, generates a cpanfile.snapshot pinning exact resolved versions, but it is a separate tool a project must opt into. Maven takes a different approach entirely: because pom.xml typically pins an exact version number per dependency already (as shown in the previous example), a Maven build is largely reproducible without any separate lockfile format, though transitive dependencies can still resolve differently across time unless explicitly managed with a dependencyManagement block. Gradle, the other major Java build tool, offers an explicit opt-in lockfile mechanism closer in spirit to Carton's snapshot file, for teams that want that stronger guarantee.

Perl bundles JSON::PP directly in core Perl since 5.14, so use JSON::PP; plus encode_json/decode_json is available with no external dependency at all. Java, somewhat surprisingly given how enterprise-focused the language is, has no JSON support whatsoever in its standard library — every Java project needing JSON reaches for a third-party library from Maven Central, most commonly Google's Gson or the more feature-rich Jackson, and the resulting object-to-JSON mapping (as shown in the commented example here, since it depends on an external library the sandboxed backend cannot install) pairs especially naturally with the low-ceremony records covered earlier in this cheatsheet, since a record is already a plain, immutable data holder that a library like Gson can serialize with almost no configuration.