Go.CodeCompared.To/Java

Go needs only a package clause and a top-level func main. Java requires every piece of code to live inside a class, so even the simplest program needs a class Main wrapping a public static void main(String[] args) entry point — there is no such thing as a free-standing function in Java.

Go produces one self-contained native binary with go build — nothing else needs to be installed on the machine that runs it. Java compiles to platform-independent bytecode (.class files) with javac, and the JVM interprets and JIT-compiles that bytecode with java. The tradeoff is portability (the same .class file runs anywhere a JVM exists) for the requirement that a JVM be installed at all.

Java shares Go's // and /* */ comment forms and adds a documentation form: /** ... */ Javadoc comments attach to the following declaration and are rendered by the javadoc tool into HTML API documentation, similar in spirit to a doc comment above a Go declaration but with dedicated tooling and tags like @param and @return.

Both languages organize code into packages and import what they need. Go's package is simply the directory a file lives in, and every file in that directory shares one namespace. Java's package is a namespace declared explicitly at the top of the file (package com.example;) that is conventionally, but not necessarily, mirrored by the directory structure, and classpath resolution — not the filesystem — is what actually locates an imported class at compile and run time.

Java's var (Java 10+) mirrors Go's :=: both infer the type once, at the point of declaration, and the variable is statically typed from then on — this is not dynamic typing in either language. A key difference is scope: Java's var works only for local variables inside a method body, never for fields, parameters, or return types, whereas Go's := has the same restriction to local scope by construction (package-level declarations always use var).

Both languages have a family of fixed-width numeric types (int8/byte, int64/long, float64/double) and a boolean type spelled differently (Go's bool versus Java's boolean). Java's char is a 16-bit UTF-16 code unit, whereas Go's rune is a 32-bit Unicode code point — a Java char cannot hold every possible character on its own, which is why some Unicode characters require a Java String or a surrogate pair to represent correctly.

Java has no dedicated const keyword; the idiomatic equivalent is a static final field, static so it belongs to the class rather than each instance, and final so it cannot be reassigned after initialization. Go constants can be package-level or function-local and are evaluated at compile time; a Java static final primitive or String initialized with a constant expression is inlined by the compiler in much the same way.

Both languages have fixed-length arrays: Go's [3]int bakes the length into the type, while a Java array's length is fixed once allocated but is not part of its static type — int[] can point to an array of any length. Java exposes the length through a length field (no parentheses, unlike a method call), where Go uses the built-in len() function that also works on slices, strings, and maps.

Strings are immutable in both languages: concatenation always produces a new string, leaving the originals untouched. Under the hood a Go string is a read-only view over a byte slice, while a Java String is a full object backed by an internal byte[] — which is why Java strings support methods (greeting.length()) directly, whereas Go keeps string operations as free functions in the strings package.

Where Go collects string operations as free functions in the strings package (strings.ToUpper(text)), Java attaches them as instance methods directly on String (text.toUpperCase()). split returns a Java array rather than a slice, and printing an array directly shows its memory address, so Arrays.toString() is needed for a readable result — a common early surprise for anyone used to Go's automatic slice formatting.

Both languages use C-style format specifiers (%s, %d), so the verbs translate almost directly from Go's Printf/Sprintf to Java's printf/String.formatted(). One easy trap: Go's literal \n works fine in Printf, but idiomatic Java formatting uses %n instead, which expands to the host platform's line separator rather than always emitting a bare LF.

Both languages provide a mutable string-building type for the same reason: repeated + concatenation in a loop allocates a new string on every iteration, which is wasteful for both a Go string and an immutable Java String. Go's strings.Builder and Java's StringBuilder both accumulate into an internal, resizable buffer and only materialize the final string when asked for it — builder.String() versus builder.toString().

Arithmetic rules are identical: dividing two integers truncates toward zero in both languages, and mixing an integer with a floating-point literal (10.0 / 3.0) produces a floating-point result. Neither language does Python-style automatic promotion of int / int to a float — the programmer must convert explicitly to get a fractional answer.

Both languages wrap silently on integer overflow rather than throwing or panicking — a Go int8 and a Java byte behave identically here. Java offers an opt-in alternative Go lacks: Math.addExact(a, b) and its siblings throw ArithmeticException on overflow, useful when silent wraparound would be a bug rather than intended modular arithmetic.

This is the first clear preview of the error-handling divide covered later in this cheatsheet. Go's strconv.Atoi returns a plain (int, error) pair that the caller inspects with an if; Java's Integer.parseInt instead throws NumberFormatException on invalid input, which must be caught with try/catch — the same underlying failure, but two fundamentally different control-flow mechanisms for reporting it.

The math libraries line up almost one-to-one: Go's math package exposes free functions (math.Sqrt), while Java groups the same operations as static methods on the Math class (Math.sqrt) — a structural difference (package versus class) around functions with identical names and behavior.

A Go slice is a lightweight, built-in growable view over an array, resized by reassigning the result of append. Java has no growable sequence built into the language itself — ArrayList<T> is an ordinary generic class from the standard library, and it mutates in place with add() rather than returning a new reference. Crucially, Java generics require a boxed reference type, so a list of numbers must be declared List<Integer>, never List<int>.

Go's range yields the index and value together in one loop header. Java's enhanced for loop (for (String fruit : fruits)) yields only the value with no index, so getting both back requires either falling back to an old-style indexed loop as shown here, or streaming with IntStream.range(0, fruits.size()) — there is no single built-in construct that mirrors Go's two-value range exactly.

Go's map is a built-in type with literal syntax and the comma-ok idiom (value, ok := m[key]) for checking presence in a single expression. Java's HashMap is an ordinary library class: put/get replace index syntax, and checking for a key takes two separate calls, containsKey then get — or one call to getOrDefault when a fallback value is acceptable. get on a missing key returns null rather than raising, which is its own trap covered later.

Go's range over a map yields the key and value directly. Java requires iterating entrySet() and pulling the key and value back out of each Map.Entry — more ceremony for the same result. Neither language guarantees iteration order for a plain hash map: Go randomizes it deliberately (to stop code from accidentally depending on it), while Java's HashMap order simply falls out of the hash table's internal layout and should not be relied upon either.

Java has a dedicated Set<T> interface with a HashSet implementation, matching the mathematical notion of a set directly. Go has no set type at all — the standard idiom is a map[T]struct{}, using the empty struct as a zero-byte value because only the keys matter. Anyone coming from Java tends to find this idiom surprising the first time they see it.

The branching structure is identical, but the syntax differs in a detail Go programmers must consciously relearn: Go forbids parentheses around the condition and requires braces, while Java requires parentheses around the condition, if (temperature > 30), and makes the braces optional for a single statement (though nearly every style guide keeps them for clarity).

Modern Java (14+) added a switch expression using -> arrows that directly produces a value, closing much of the gap with Go's switch statement — both allow comma-separated case values and both stop after a matching case with no fall-through by default. The traditional Java switch statement using colons still exists and does fall through without an explicit break, a legacy trap that the arrow form was specifically designed to eliminate.

Go famously folds every kind of loop — counted, conditional, and infinite — into a single for keyword, distinguished only by which clauses are present. Java keeps the traditional trio of loop keywords from C: for for counted loops, while for condition-first loops, and do/while for condition-last loops, plus the enhanced for for iterating a collection.

Java has a ternary operator, condition ? whenTrue : whenFalse, inherited from C. Go's designers deliberately left it out, judging that a full if/else statement is clear enough and that a ternary tends to be overused for compound conditions — so the same one-line decision that is idiomatic Java requires four lines of Go.

Go has genuine free-standing functions declared at package level. Java has no equivalent — every method must live inside a class, so a helper called from main must be declared static on that class to be callable without an instance. This is a direct consequence of Java being class-rooted: there is simply no syntax for code that exists outside of some class.

Go methods can return multiple values directly, (int, int), unpacked with multiple assignment at the call site — the mechanism the language leans on heavily for its (value, error) convention. Java methods can only return one value, so returning several related values means bundling them into an object, and a Java record (16+) is the concise, idiomatic way to do that without hand-writing a full class with a constructor, getters, and equals/hashCode.

Variadic parameters are nearly identical in spelling and behavior: Go's numbers ...int becomes Java's int... numbers, and inside the method both are treated as an ordinary sequence (a slice in Go, an array in Java). Both require the variadic parameter to be last in the parameter list, and both let the caller pass zero or more arguments directly without wrapping them in a literal.

Go treats functions as ordinary values with their own function type, so func(int) int can be assigned to a variable directly. Java has no true function type; a lambda is really syntactic sugar for an anonymous implementation of a single-method interface — here Function<Integer, Integer> from java.util.function — and it must be invoked through that interface's method (.apply(21)), never called directly like doubler(21).

This is one of the biggest structural differences between the languages. Go has no classes at all — a struct is purely a collection of fields, and there is no constructor syntax (a struct literal fills fields directly, and unset fields simply take their zero value). Java's class bundles fields with a mandatory constructor, and printing an instance directly calls toString(), which must be overridden explicitly to produce readable output — Go's %+v verb gives readable field-by-field output automatically, with no method to write.

A Go method is a regular function with an extra (rectangle Rectangle) receiver clause attaching it to a type — the method and the type it operates on are declared separately and can even live in different files. A Java method is defined inside the class body itself and refers to the instance implicitly through this rather than a named receiver parameter. Go additionally distinguishes value receivers (a copy) from pointer receivers (a reference) explicitly in the signature; Java objects are always accessed through a reference, so that distinction does not arise.

Every Go type has a well-defined zero value — 0 for numbers, "" for strings, nil for pointers and slices — so var counter Counter is immediately usable with no constructor call at all. Java gives instance fields a default value too (0, false, null), but an object itself must always be brought into existence with new; there is no way to have a usable Counter without calling some constructor, even an implicit no-argument one the compiler generates for you.

Go signals visibility with capitalization alone: an identifier starting with an uppercase letter is exported (visible outside its package); lowercase is package-private. There is no public/private keyword at all. Java instead has an explicit set of access-modifier keywords — public, protected, private, and package-private (the default, no keyword) — applied individually to each field and method, giving finer-grained control than Go's all-or-nothing-per-identifier rule at the cost of far more boilerplate.

Go has no extends and no class hierarchy at all. Instead, a struct can embed another struct as an anonymous field, and the outer type automatically gains ("promotes") the embedded type's fields and methods, callable as if they belonged to it directly — but a Dog is never actually an Animal in the type system, it merely has one built in. Java's extends creates a true is-a relationship: a Dog reference can be assigned to an Animal variable, and virtual dispatch means overriding speak() in Dog changes what runs even when called through an Animal-typed reference — a form of polymorphism embedding does not provide.

This example exposes the sharpest practical difference between embedding and inheritance. In Go, Base.Announce() calls Base.Describe() — embedding is not polymorphic, so overriding Describe on Derived has no effect on what Base's own methods call internally. In Java, every non-final, non-private method is virtual by default, so Base.announce() resolves describe() dynamically and picks up Derived's override at runtime. A Go programmer new to Java should expect this behavior change, not assume embedding and inheritance are interchangeable.

Java's abstract class can mix required methods (abstract double area();, no body, must be implemented) with concrete shared methods (describe(), implemented once and inherited by every subclass) — a middle ground between a pure interface and a fully-implemented class. Go has nothing directly equivalent, since it lacks inheritance entirely; the idiomatic replacement splits the same idea into an interface for the required contract and a free function for the shared behavior, as shown on the Go side.

This is the single biggest philosophical gap between Go and Java. Go interfaces are satisfied structurally: Dog implements Speaker simply by having a method with a matching name and signature — there is no implements clause, no declared relationship anywhere, and Dog may not even know Speaker exists. Java interfaces are satisfied nominally: a class must explicitly write implements Speaker, and the compiler checks that contract exactly where it is declared. Go's approach means interfaces can be defined after the fact by whoever needs one (even in a completely different package than the implementing type); Java's approach means the relationship is always visible right at the class declaration, at the cost of requiring foresight or after-the-fact edits to add a new interface.

Go's structural typing means a single type can satisfy any number of interfaces without ever naming them, which is why the Go standard library defines so many tiny, single-method interfaces (io.Reader, io.Writer, fmt.Stringer) — any type with the right method automatically qualifies. Java allows the same outcome, a class implementing multiple interfaces, but every one of them must be listed explicitly in a comma-separated implements clause, so extending a class to satisfy a newly discovered interface always requires editing that class's source.

Since Java 8, an interface method marked default can carry an implementation, so greet() works for every implementer that supplies name(), with no free-standing helper function needed. Go interfaces cannot do this at all — they remain pure method signatures with zero implementation, so any shared behavior across implementers must live outside the interface, either as a free function (as shown on the Go side) or via struct embedding.

Go's type switch, switch value := shape.(type), inspects the concrete type behind an interface value and binds it in each case — the idiomatic way to recover specific behavior from a general interface. Modern Java (21+) offers a strikingly similar-looking feature: pattern matching for switch, which deconstructs a sealed interface's permitted implementations. The key difference is exhaustiveness — because Shape is declared sealed permits Circle, Square, the compiler knows those are the only two possible cases and requires no default branch at all, catching a missing case at compile time rather than letting it fall through silently as Go's type switch would without an explicit default.

This is the other headline philosophical difference alongside interfaces. Go has no exceptions for ordinary error conditions: a failing operation returns an error as an ordinary value alongside its result, and the caller is expected — by convention, not compiler enforcement — to check if err != nil after every call that can fail. Java routes failures through a completely separate control-flow channel: throw unwinds the stack immediately, skipping all remaining code until a matching catch block is found, however many function calls away that may be. A Go programmer's instinct to check a return value for failure has no direct target in Java — the failure never appears in the return value at all.

Java splits its exceptions into two enforced categories with no Go equivalent to either. A checked exception (any subclass of Exception other than RuntimeException) must appear in a throws clause on every method that can propagate it, and every caller must either catch it or declare it themselves — the compiler rejects code that ignores the possibility. An unchecked exception (RuntimeException and its subclasses, like ArithmeticException or NullPointerException) requires no declaration and can be silently ignored by the caller with the code still compiling. Go simply has none of this machinery: every error is a plain value, and nothing in the language forces a caller to inspect it — the closest Go gets to "checked" is the community convention (and linters like errcheck) that flag an unchecked error, not the compiler itself.

Both languages let a higher-level failure carry a lower-level one as context, but the mechanism differs. Go's %w verb in fmt.Errorf wraps an existing error inside a new one, and errors.Unwrap (or errors.Is/errors.As) walks that chain back to the original — errors remain ordinary values throughout. Java's exception constructors accept an optional cause argument, and getCause() retrieves it; because exceptions carry a captured stack trace at the point they were constructed, the cause chain shown by an uncaught exception's printed trace typically gives a Java programmer more context for free than Go's wrapped error chain does, at the cost of the stack-trace-capture overhead on every throw.

Both languages guarantee cleanup code runs whether or not the function completes normally. Go's defer schedules a call to run when the enclosing function returns, regardless of whether it returned normally or is unwinding from a panic. Java's finally block, attached to a try, runs whether the try completed normally, threw an exception, or hit a return — the same guarantee, expressed as a dedicated clause of the exception-handling syntax rather than a general-purpose statement scheduler.

Go's defer is a general-purpose mechanism: any function call can be deferred, and it runs when the enclosing function returns, in last-in-first-out order relative to other deferred calls. Java's try-with-resources is narrower but more automatic: any object implementing AutoCloseable declared in the parentheses of a try is closed automatically at the end of that block, not the whole method, and requires no explicit close() call to remember. Where a Go function typically pairs an open... call with an immediately following defer resource.Close(), idiomatic Java expresses the same open-use-close lifecycle as the shape of the try statement itself.

Both mechanisms agree on ordering — the most recently acquired resource is released first — which matters when resources depend on one another (a connection opened after a socket must close before that socket does). Go achieves this because defer is a stack: each deferred call is pushed and popped in reverse order. Java achieves the identical LIFO order because try-with-resources closes each declared resource in the reverse of its declaration order, semicolon-separated in the same parentheses.

Go generics arrived in 1.18 and are deliberately simple: a type parameter is constrained by a type set, such as int | float64, listing exactly which concrete types are allowed. Java generics predate Go's by well over a decade and are constrained by bounds expressed through interfaces, such as T extends Comparable<T>, which admits any type implementing that interface rather than an explicit enumerated list — more open-ended, but also why Java needed an interface like Comparable to express "anything orderable" where Go can just list the primitive types directly.

Generic structs and generic classes look nearly identical: Pair[T any] versus Pair<T>, with the unconstrained placeholder spelled any in Go and simply bare T in Java. The instantiation syntax differs slightly — Go repeats the type argument explicitly, Pair[string]{...}, while Java infers it from the diamond operator <> when the constructor arguments make it unambiguous, as in new Pair<>("a", "b").

This is a deep implementation difference that occasionally surfaces as a real limitation. Go compiles a distinct specialized version of a generic function for each concrete type it is instantiated with (monomorphization), so the compiled code always has full, exact type information at runtime. Java instead erases type parameters after compile-time checking — at runtime, List<Integer> and List<String> are both just List, with no way to recover T via reflection or instanceof. This is precisely why Java cannot write new T() inside a generic method, and why arrays of a generic type parameter are disallowed — limitations Go's generics do not share.

Go's go keyword launches a goroutine: a lightweight function scheduled cooperatively by the Go runtime, cheap enough that a program can spawn hundreds of thousands of them, starting at only a few kilobytes of stack each. Java's Thread traditionally maps to a real, comparatively heavyweight operating-system thread, so spawning thousands of them was historically expensive — a genuine capability gap that only closed with Java 21's virtual threads (see the next entry). waitGroup.Wait() and thread.join() serve the same purpose: blocking until the concurrent work finishes.

Virtual threads, finalized in Java 21, are the modern bridge point between the two languages' concurrency models. Like a goroutine, a virtual thread is scheduled by the JVM onto a small pool of real OS threads rather than consuming one itself, so a Java program can now spawn hundreds of thousands of virtual threads just as cheaply as a Go program spawns goroutines. The programming model still looks like traditional Java threads (Thread, ExecutorService, blocking calls) rather than adopting Go's channel-based style, but the cost profile that used to make "one thread per request" impractical in Java no longer applies.

Go's channels are a language-level primitive with dedicated syntax (chan, <-, range, close) built around the philosophy "do not communicate by sharing memory; share memory by communicating." Java has no channel syntax in the language itself, but java.util.concurrent.BlockingQueue provides the same fundamental capability as an ordinary library class: put() blocks when the queue is full (mirroring a send on an unbuffered or full channel), and take() blocks when it is empty (mirroring a receive). Java has no built-in equivalent of closing a channel to signal "no more values" — the producer and consumer must agree on their own termination protocol, such as a sentinel value or a separate completion signal.

Go's select statement waits on multiple channel operations at once and proceeds with whichever is ready first, a language-level construct with no direct Java equivalent. The closest match in Java's concurrency library is CompletableFuture.anyOf(...), which completes as soon as any of several asynchronous computations finishes. The Java version is coarser-grained — it races entire results rather than individual channel sends and receives, and it lacks select's default case for a non-blocking attempt — but it addresses the same underlying need: proceeding with whichever of several concurrent operations finishes first.

Every Java class implicitly extends java.lang.Object unless it names a different superclass, so every reference type automatically inherits toString(), equals(), hashCode(), and a handful of other methods — which is why an unfamiliar object can always be printed or compared, even badly, without writing any code. Go has no such universal root type; every type stands alone unless a piece of code explicitly asks for the empty interface any (an alias for interface{}), which is structurally satisfied by literally everything but confers no methods of its own.

This surprises nearly every programmer coming from a language without boxed primitives. The Java compiler autoboxes an int literal into an Integer object, and the JVM caches (and reuses) Integer instances for the range -128 to 127 as a performance optimization — so == on two boxed 100s happens to return true because they are literally the same cached object, while == on two boxed 200s returns false because they fall outside the cache and are separate objects. Go has no boxing to speak of: an int is always a plain value, and == always compares those values directly with no object-identity trap lurking underneath. The reliable fix in Java is the same one described in the next entry: never use == to compare boxed values, always use .equals().

This is the single most common Java bug for programmers arriving from a language where == means value equality. In Java, == on reference types (which includes String and every custom class) compares object identity — are these the exact same object in memory — never content. .equals() is the method that must be called for content comparison, and a class only gets meaningful content-based .equals() behavior if it overrides the default (identity-based) implementation inherited from Object. Go sidesteps this entire class of bug: == on strings and on comparable structs always performs a genuine value comparison, so there is no separate method to remember to call.

Both languages have an absent-reference value spelled almost identically (Go's nil, Java's null) and both let a programmer forget to check for it. The consequence differs sharply: dereferencing a nil pointer in Go triggers a runtime panic that, left unhandled, crashes the whole program with a stack trace pointing at the dereference. Dereferencing null in Java throws a catchable NullPointerException that unwinds like any other exception and can be caught with an ordinary try/catch — genuinely recoverable, unlike an unrecovered Go panic, though in practice a NullPointerException almost always indicates a bug that should be fixed rather than caught.

Go was designed around a small, deliberately minimal keyword set and a strong cultural bias toward brevity — no annotations, no checked-exception boilerplate, no access-modifier ceremony for a simple data holder. Traditional Java earned a reputation for verbosity precisely because a simple data class once needed a hand-written constructor, getters, equals(), hashCode(), and toString() — dozens of lines for what a Go struct expresses in three. Modern Java has narrowed this gap considerably: a record (shown here, Java 16+) generates all of that boilerplate automatically from a single-line declaration, though Java's surface area — interfaces, abstract classes, annotations, four access-modifier levels, checked exceptions — remains considerably larger than Go's twenty-five keywords by design.

This is a real maintenance cost that surprises Go programmers the first time they hit it. In Go, every fallible function already returns an error, so adding a new failure case deep in a call chain never changes any function's signature — the caller was always free to check or ignore it. In Java, a checked exception forces every intermediate method between where it is thrown and where it is caught to add it to their own throws clause, purely to satisfy the compiler, even if that intermediate method has no interest in the exception itself — a change several layers down can ripple upward through signatures that otherwise would not need to change at all. This cost is exactly why many modern Java libraries and style guides favor unchecked exceptions for most application-level failures, reserving checked exceptions for cases the caller genuinely must handle.