This course sits deliberately next to Java throughout — not because the two are interchangeable, but because they share more architecture than most language pairs on this site, and diverge in specific, namable places. This chapter starts with what they share.

The CLR vs. the JVM

C# compiles to IL (Intermediate Language) — not directly to machine code — and the CLR (Common Language Runtime) JIT-compiles that IL at runtime, exactly the same two-stage model java1-1 described for the JVM and Java bytecode. This is a genuine point of similarity worth naming explicitly, not a coincidence — C# inherited this architecture on purpose, the same "write once, run wherever the runtime exists" tradeoff Java made first.

The dotnet CLI

Where java1-1 used two separate tools — javac to compile, java to run — dotnet is one unified CLI covering project scaffolding, building, and running. dotnet run alone does what javac + java together did.

Top-Level Statements

Since C# 9, a file can skip the class-and-Main boilerplate entirely for the simplest programs — a real, direct contrast to java1-1's strict "everything lives in a class, with an explicit public static void Main" requirement. Under the hood, though, the compiler still generates that exact class-and-Main shape automatically — this is real syntactic sugar over the same model, not a fundamentally different one.

What's Really There

This is the explicit, traditional form — the same shape java1-1 required from the very first line. Larger, real applications generally still write Main explicitly; top-level statements are mainly a convenience for small programs, scripts, and quick experiments.

C#'s Origin as Microsoft's Direct Answer to Java

C# was created in 2000, led by Anders Hejlsberg — previously the architect behind Turbo Pascal and Delphi, later the designer of TypeScript. Its creation followed directly from a Sun Microsystems lawsuit over Microsoft's own non-compliant Java implementation, J++ — rather than continue fighting over Java itself, Microsoft built its own language and runtime from scratch. This is real, documented history, not just a marketing framing — and it's exactly why C# and Java's architectures line up as closely as they do.

Coding Challenges

java1-2 drew a hard line: eight built-in primitives, everything else a reference type, no way for a programmer to add to either side. C# keeps the same two-category split — but genuinely lets you choose which side a new type belongs on.

Value Types vs. Reference Types

A value type holds its data directly — assigning or passing it copies the actual data. A reference type holds a reference to data stored elsewhere — assigning or passing it copies the reference, not the underlying data. This is C#'s own version of java1-2's primitive-vs-reference split, but with a genuine structural difference: in Java, only the eight built-in primitives are ever value-like — every programmer-defined type is automatically a reference type, no exceptions. In C#, a programmer can define a brand-new value type of their own.

struct vs. class

struct declares a value type; class declares a reference type — otherwise, the two look almost identical to write. This is the real, structural choice java1-4's own classes never offered: in Java, every custom type is unconditionally a reference type, full stop.

Built-in Types Are Just Structs

Here's the real reveal: int, double, and bool aren't magic keywords divorced from the type system — they're built-in aliases for real structs (System.Int32, System.Double, System.Boolean). Because they're genuinely structs, they can call methods directly, no wrapping required. This is a real, structural contrast with java1-2's own primitives, which aren't objects at all — Java's int can never call a method on itself; it must first be boxed into an Integer.

var Type Inference

var lets the compiler infer a variable's type from its initializer — the type is fixed permanently at compile time, exactly as if it had been spelled out explicitly. This is genuinely still static typing, in the same spirit as C++'s auto, not a loophole into dynamic typing.

Nullable Value Types

A value type genuinely can't be null by default — it's real data sitting directly in the variable, not a reference that could point to nothing. The ? suffix opts a value type into nullability through Nullable<T>, a wrapper struct. This is a separate, earlier feature from Course 2's own nullable reference types chapter, which addresses the opposite problem — reference types, which could always be null by default until that later feature opted them out of it.

Coding Challenges

Most of C#'s operators are shared syntax with every C-family language already covered on this site. The genuine differences are concentrated in one place: switch, and two operators Java has no direct equivalent for at all.

Standard Operators & Integer Division

Arithmetic, relational, and logical operators behave exactly as in C/C++/Java. Integer division still truncates toward zero — the same behavior c1-3 and java1-3 already covered, inherited unchanged.

switch Statements — Fallthrough Forbidden by Default

This is a genuine, real difference worth stating plainly: C#'s switch statement forbids implicit fallthrough between non-empty case blocks — the exact opposite default of c1-3's C and java1-3's Java. A case with a statement body must end in break, return, throw, or an explicit goto case — omitting all four is a compile error, not a bug waiting to happen at runtime. Stacked empty case labels (case 1: case 2: DoSomething(); break;) are still fine, since neither label has its own body to fall out of.

switch Expressions — Pattern Matching Since Day One

C# 8 (2019) shipped switch expressions with real pattern matching already built in — genuinely before java1-3's own arrow-based switch expressions landed in Java 14 (2020). Another "C# arrived first" moment, alongside Course 2's own records chapter.

Pattern Matching in switch Expressions

Type patterns, relational guards via when, and a dedicated null pattern were all present from C# 8's initial launch — a notably richer starting point than java1-3's own simpler initial arrow-only form.

Null-Conditional and Null-Coalescing Operators

?. (null-conditional) short-circuits an entire chain to null the moment any link is null, instead of throwing. ?? (null-coalescing) supplies a fallback value only when the left-hand side is null. Neither operator has a direct Java equivalent — Java requires either manual null checks or an Optional-based rewrite to express the same idea.

Coding Challenges

Constructors and fields work almost identically to java1-4. The real divergence is in how C# handles the getter/setter pattern every Java class relies on — it's not a pattern here at all.

Constructors — Quick Recap

Same idea, same shape as java1-4's own constructors — a method sharing the class's name, no return type, run once via new.

Properties — A First-Class Language Feature

In Java, "a property" is purely a naming convention — a private field plus a hand-written getName()/setName() pair, entirely a matter of programmer discipline that java1-4's own language rules never enforce or even recognize. C# has real property syntax built directly into the language: { get; set; } alone generates a hidden backing field and both accessors automatically — one line replaces what Java requires spelling out as three separate members.

Full Property Syntax with Custom Logic

A property can run genuine logic in its accessors — validation, transformation, computed values — while the call site still reads exactly like ordinary field access: customer.Name = " Alice "; silently runs the trim logic. This is a real, different call-site ergonomic from Java's explicit setName(...) method call, which always visibly announces itself as a method call.

Read-Only and Init-Only Properties

A get-only property can only be assigned inside the constructor. init (C# 9) is slightly more flexible — it allows object-initializer syntax to set the property exactly once, at construction time, then locks it — the same mechanism Course 2's own records chapter builds on internally for its immutable, boilerplate-free data carriers.

Access Modifiers, Revisited

C# has the same public/private/protected plus a genuine fourth level — but a structurally different one than java1-4's package-private. C#'s internal means visible anywhere within the same assembly (a compiled project/DLL), a unit defined by how the project is built, not by folder or namespace structure the way Java's package-private is tied to the package a file physically sits in.

Coding Challenges

This is the chapter where C# and Java's shared architecture stops predicting shared behavior. java1-5 made every instance method virtual unless told otherwise. C# does the opposite.

base and Inheritance Basics

Same underlying idea as java1-5, different keywords — single inheritance via :, a base constructor call via base(...).

virtual and override — Required Explicitly

Here's the real reversal: in C#, a method is not dynamically dispatched by default. java1-5 established that every Java instance method is virtual unless explicitly marked final/private/static. C# requires the base class to mark a method virtual and the derived class to mark its own version override — without both keywords present, calling that method through a base-typed reference always runs the base class's own version, regardless of the object's real runtime type.

What Happens Without virtual/override — Method Hiding

Redeclaring a method with the same signature but no override creates an entirely different, non-polymorphic mechanism called method hiding — the new keyword makes this explicit. Which version runs depends on the reference's declared type, not the object's real runtime type — the opposite of what java1-5 trained every reader to expect from an object hierarchy.

Why C# Requires Opt-In Virtual

Two real, deliberate reasons, not accidents of history: a non-virtual method call can be resolved at compile time, avoiding the runtime dispatch-table lookup a virtual call requires — a genuine performance difference at scale. And a base class author is forced to explicitly decide, and effectively document, which methods are meant to be extension points — rather than every method automatically becoming one whether the original author intended it or not, as java1-5's virtual-by-default makes true for every Java class.

sealed — Preventing Further Overriding

sealed override stops a further subclass from overriding an already-overridden method; sealed class prevents any further inheritance at all — genuinely comparable to Kotlin's own classes being closed to inheritance by default, an ironic point of alignment given C# otherwise opts into virtual dispatch the same non-default way Kotlin does.

Coding Challenges

This time Java arrived first: java1-6's default interface methods shipped in Java 8 (2014), years before C# 8 (2019) added the same idea to C#. But C# didn't stop there — it added something Java's interface system has no equivalent for at all.

Interfaces — Recap

Same underlying idea as java1-6 — a pure contract, a class implements ... except C# spells that keyword :, the same syntax used for class inheritance. Interface members are implicitly public, with no modifier needed.

Default Interface Methods (C# 8) — Java Arrived First This Time

C# 8 added default interface method bodies — the identical idea java1-6 described for Java 8, five years earlier. Worth stating plainly, since it varies chapter to chapter: sometimes C# arrives first (switch expressions, records), and sometimes Java does, as here.

Multiple Interface Implementation — The Diamond Problem, Again

The same narrow diamond problem java1-6 covered resurfaces here — two conflicting default implementations force an explicit resolution, or the class fails to compile. The syntax differs (a cast to the interface type, rather than Java's InterfaceName.super.method()), but the underlying requirement is identical: the compiler refuses to guess.

Explicit Interface Implementation — No Java Equivalent

Here's the genuine reveal: java1-6's own diamond-problem fix forces a single, explicit resolution — one implementation wins. C#'s explicit interface implementation lets a class keep both conflicting implementations simultaneously, each one only reachable through the specific interface type it belongs to. This resolves a real name-collision scenario Java's interface system has no mechanism for at all — Java would require renaming one of the two methods; C# doesn't.

Abstract Classes — Quick Recap

Same idea as java1-6's own abstract classes — real state, constructors, and concrete methods alongside abstract ones, still limited to single inheritance.

Coding Challenges

java1-7 positioned Java's checked exceptions as a real middle ground between C++'s unenforced exceptions and Rust's Result<T, E>. C#'s designers looked at that same middle ground and deliberately rejected it — this chapter explains why, with their own stated reasoning.

try/catch/finally — Same Shape

Structurally identical to java1-7 — try, a typed catch, an unconditional finally. The real divergence isn't the syntax.

Every C# Exception Is Unchecked

C# has no checked-exception concept at all. Every exception, without exception, behaves the way java1-7 described for RuntimeException — a method can throw anything, with zero compiler-enforced acknowledgment, ever. No throws clause exists in C#'s syntax to require in the first place.

Why C# Rejected Checked Exceptions

This was a deliberate design decision, not an oversight — Anders Hejlsberg (csharp1-1's own origin-story architect) has spoken publicly about the specific reasoning. Two real, documented critiques of java1-7's own model: checked exceptions don't version well — adding one new checked exception to a widely-used method's signature breaks every existing caller that doesn't already handle it, a real practical cost in library evolution. And in practice, checked exceptions get "handled" via empty catch blocks or wrapped indiscriminately in a generic RuntimeException just to satisfy the compiler — arguably making real code worse, not safer, than leaving the choice to the programmer's judgment.

XML Doc Comments as the Real (Weaker) Substitute

C# lets an API author document what a method might throw via an XML doc comment's <exception> tag, surfaced in IntelliSense — but nothing here is compiler-enforced at all. It's purely informational, a real, direct contrast against java1-7's own compiler-enforced throws clause.

Exception Filters — A Genuinely Unique Addition

catch (...) when (condition) is a real feature with no direct Java equivalent — a catch block only fires when its exception type and a runtime condition both hold, avoiding a nested if statement (and a re-throw of everything that doesn't match) inside a broader catch.

using — C#'s Answer to try-with-resources

Any type implementing IDisposable works with using, calling Dispose() automatically — genuinely comparable to java1-7's try-with-resources/AutoCloseable, and to cpp1-5's RAII. C# 8's using declaration form (shown above, no extra braces) is even more concise syntactically than Java's own block-scoped try(...) syntax.

Coding Challenges

Fundamentals closes with C#'s everyday collections — and a first look at the feature that touches nearly every one of them, deferred to Course 2's own full chapter, but too central to leave out entirely here.

List<T> — A Growable Collection

Nearly identical in behavior to java1-8's own List/ArrayList — grows automatically, generic. C#'s generics are reified rather than erased, a real difference Course 2's own Generics In Depth chapter covers in full; this chapter stays at the surface level.

Dictionary<TKey, TValue>

Comparable to java1-8/java2-2's own Map/HashMap — key-value pairs, average constant-time lookup. C#'s indexer syntax (ages["Alice"]) reads slightly more concisely than Java's explicit .put()/.get() calls, though the underlying idea is identical.

Iterating — foreach

Directly comparable to Java's own enhanced for loop — same purpose, different keyword.

A First Taste of LINQ

LINQ — Language Integrated Query — shipped in C# 3.0, back in 2007, genuinely comparable to java2-4's own Streams API but arriving seven years earlier. Another "C# first" moment, like csharp1-3's own switch expressions. LINQ offers two syntaxes for the same underlying query: fluent method chaining (.Where().Select()), and a genuinely unique SQL-like query syntax baked directly into C#'s own grammar — something neither Java nor most other languages on this site offer as native syntax at all.

Why Preview LINQ Now

LINQ works over anything implementing IEnumerable<T> — which includes List<T>, Dictionary<TKey,TValue>, arrays, and every collection this chapter just introduced. That's exactly why it belongs here rather than waiting entirely for Course 2 — it's the natural next step for everything just covered, not a separate, unrelated topic.

Coding Challenges