C# vs Java: składnia, środowisko, generyki, LINQ i czego się uczyć

C# i Java to bliscy krewni. Oba to statycznie typowane, obiektowe języki z odśmiecaczem pamięci i składnią w stylu C, oba kompilują się do kodu bajtowego dla maszyny wirtualnej i oba są używane w dużych systemach backendowych. C# powstał w 2002 roku częściowo jako odpowiedź Microsoftu na Javę, a przez dwie dekady oba języki zapożyczały od siebie funkcje (lambdy, generyki, rekordy, dopasowywanie wzorców). Programista, który zna jeden z nich, niemal od razu przeczyta drugi.

Różnice, które mają znaczenie na co dzień, są mniejsze i bardziej konkretne. Ta strona omawia je z kodem: fragmenty w C# możesz uruchomić, a Java jest w statycznych blokach dla porównania.

W skrócie

Składnia: w większości taka sama

Klasy, metody, if, for, while, switch, try/catch czyta się niemal identycznie. Widoczne różnice to konwencje nazewnictwa i kilka słów kluczowych: metody w C# są w PascalCase (ToUpper, WriteLine), w Javie w camelCase (toUpperCase, println); C# pisze string i bool, Java String i boolean; dziedziczenie to class Dog : Animal w C# i class Dog extends Animal w Javie.

// Java
import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        names.add("Ana");
        names.add("Ben");
        for (String n : names) {
            System.out.println(n.toUpperCase());
        }
    }
}

using System;
using System.Collections.Generic;

class Program
{
    static void Main()
    {
        var names = new List<string> { "Ana", "Ben" };
        foreach (string n in names)
        {
            Console.WriteLine(n.ToUpper());
        }
    }
}

Wynik:

ANA
BEN

C# porównuje też napisy po wartości przez ==, co usuwa jeden z klasycznych błędów początkujących w Javie: tam == na dwóch obiektach String porównuje referencje, więc dwa równe napisy zbudowane w czasie działania (wczytane z wejścia, sklejone) mogą okazać się nierówne.

Właściwości zamiast getterów i setterów

Klasy w Javie udostępniają stan przez metody getName() i setName(), zwykle generowane przez IDE lub Lombok. C# ma właściwości: składowe, które czyta się jak pola, ale które wykonują kod.

// Java
public class Product {
    private double price;
    public double getPrice() { return price; }
    public void setPrice(double price) {
        if (price < 0) throw new IllegalArgumentException("negative");
        this.price = price;
    }
}

using System;

class Product
{
    public string Name { get; set; }        // auto-property

    private decimal price;
    public decimal Price                     // property with validation
    {
        get { return price; }
        set
        {
            if (value < 0) throw new ArgumentException("Price cannot be negative");
            price = value;
        }
    }
}

class Program
{
    static void Main()
    {
        var p = new Product { Name = "Mug", Price = 8.50m };
        p.Price += 1.00m;                    // reads and writes like a field
        Console.WriteLine($"{p.Name}: {p.Price:F2}");
    }
}

Wynik:

Mug: 9.50

Inicjalizator obiektu new Product { Name = ..., Price = ... } ustawia właściwości zaraz po utworzeniu obiektu. Rekordy w Javie (Java 16) pokrywają przypadek niemodyfikowalnych danych; C# też ma rekordy (C# 9), a do tego właściwości do całej reszty.

Typy wartościowe: struktury

W Javie każdy typ zdefiniowany przez użytkownika jest typem referencyjnym przechowywanym na stercie; wartościami jest tylko osiem typów prostych (int, double, ...). C# pozwala definiować własne typy wartościowe przez struct. Struktura jest kopiowana przy przypisaniu i może być przechowywana bezpośrednio w tablicach i innych obiektach, bez osobnej alokacji na stercie.

using System;

struct Point
{
    public int X;
    public int Y;
    public Point(int x, int y) { X = x; Y = y; }
}

class Program
{
    static void Main()
    {
        var a = new Point(1, 2);
        var b = a;          // copies the whole value
        b.X = 99;
        Console.WriteLine($"a = ({a.X}, {a.Y})");
        Console.WriteLine($"b = ({b.X}, {b.Y})");

        var grid = new Point[1000]; // one block of 1000 points, not 1000 objects
        Console.WriteLine(grid.Length);
    }
}

Wynik:

a = (1, 2)
b = (99, 2)
1000

Ma to znaczenie w grach i kodzie numerycznym, gdzie miliony małych obiektów obciążałyby odśmiecacz pamięci. Zobacz struktury.

Generyki: reifikowane a wymazywane

Java wymazuje argumenty typów generycznych w czasie kompilacji: w czasie działania List<Integer> to po prostu List, a List<int> jest niedozwolone (dostajesz opakowane obiekty Integer). C# zachowuje argumenty typów w czasie działania, więc List<int> przechowuje surowe liczby int, a kod może zapytać, czym jest T.

using System;
using System.Collections.Generic;

class Program
{
    static string Describe<T>(List<T> items)
    {
        return $"{items.Count} items of type {typeof(T).Name}";
    }

    static T Create<T>() where T : new()
    {
        return new T();     // impossible in Java: T is erased
    }

    static void Main()
    {
        Console.WriteLine(Describe(new List<int> { 1, 2, 3 }));
        Console.WriteLine(Describe(new List<string> { "a" }));

        var list = Create<List<decimal>>();
        Console.WriteLine(list.GetType().Name);
    }
}

Wynik:

3 items of type Int32
1 items of type String
List`1

typeof(T) i new T() działają, bo środowisko uruchomieniowe zna T. W Javie oba to błędy kompilacji, a typowe obejście to przekazywanie obiektu Class<T>.

LINQ a strumienie

Oba języki mają płynne API do filtrowania i przekształcania kolekcji. W Javie to Streams API (Java 8); w C# to LINQ (C# 3), który ma też składnię zapytań i działa na bazach danych przez Entity Framework.

// Java
List<String> expensive = products.stream()
    .filter(p -> p.getPrice() > 20)
    .sorted(Comparator.comparing(Product::getPrice))
    .map(Product::getName)
    .collect(Collectors.toList());

using System;
using System.Linq;

class Program
{
    static void Main()
    {
        var products = new[]
        {
            new { Name = "Lamp", Price = 35m },
            new { Name = "Pen", Price = 2m },
            new { Name = "Chair", Price = 80m },
            new { Name = "Mug", Price = 9m }
        };

        var expensive = products
            .Where(p => p.Price > 20)
            .OrderBy(p => p.Price)
            .Select(p => p.Name)
            .ToList();
        Console.WriteLine(string.Join(", ", expensive));

        var total = products.Sum(p => p.Price);
        Console.WriteLine($"Total: {total}");
    }
}

Wynik:

Lamp, Chair
Total: 126

Operacje odpowiadają sobie jeden do jednego (filter to Where, map to Select, collect(toList()) to ToList()), a wersje w C# nie potrzebują stream() ani kolektora. Obiekty new { Name = ..., Price = ... } to typy anonimowe, które nie mają bezpośredniego odpowiednika w Javie.

Asynchroniczność i współbieżność

C# wprowadził async/await w 2012 roku: metoda async zwraca Task, a await wstrzymuje ją bez blokowania wątku. JavaScript, Python i Rust przejęły później te same słowa kluczowe. Java poszła inną drogą: łańcuchy CompletableFuture, a od Javy 21 wątki wirtualne, dzięki którym zwykły blokujący kod jest tani.

// C#
async Task<string> LoadAsync(HttpClient http, string url)
{
    string body = await http.GetStringAsync(url);
    return body.Substring(0, 100);
}

// Java 21 with virtual threads: plain blocking code on a cheap thread
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> client.send(request, BodyHandlers.ofString()));
}

Oba podejścia skalują się do wielu równoczesnych żądań. C# pokazuje asynchroniczność w sygnaturach metod; Java ukrywa ją w środowisku uruchomieniowym.

Wyjątki, operatory i mniejsze różnice

• Wyjątki kontrolowane. Java wymusza, żeby metoda deklarowała lub łapała pewne wyjątki (throws IOException). C# w ogóle nie ma wyjątków kontrolowanych.
• Przeciążanie operatorów. C# pozwala typom definiować +, ==, < i podobne, dlatego arytmetyka na decimal i DateTime czyta się naturalnie. Java na to nie pozwala (BigDecimal.add).
• Domyślna wirtualność. Metody w Javie można nadpisywać, chyba że są oznaczone final; metody w C# muszą być oznaczone virtual, żeby dało się je nadpisać, a nadpisanie musi mieć override.
• Metody rozszerzające. C# może dodawać metody do istniejących typów ("text".IsPalindrome()); Java nie.
• Typy wartościowe nullable. int? w C# to int, który może być null; Java używa opakowanego Integer.
• Typy bez znaku. C# ma uint, ulong, ushort i byte bez znaku; byte w Javie jest ze znakiem, a poza 16-bitowym char Java nie ma typów całkowitych bez znaku.

Ekosystem, praca i czego się uczyć

Ekosystem Javy jest większy w świecie serwerów open source: Spring, Kafka, Spark, Hadoop, Elasticsearch i większość projektów Apache to Java. Aplikacje na Androida pisze się w Kotlinie lub Javie. C# ma bardziej zintegrowany stos: jeden dostawca utrzymuje język, środowisko uruchomieniowe, framework webowy (ASP.NET Core), ORM (Entity Framework) i główne IDE (Visual Studio), a Unity stawia go w centrum tworzenia gier.

Oba języki mają duże rynki pracy, a proporcje między nimi zależą od regionu i branży. C# jest mocny w firmach opartych na Microsoft i Azure, w oprogramowaniu dla finansów i ochrony zdrowia oraz w studiach gier.

Wybierz C#, jeśli chcesz tworzyć gry w Unity, budować aplikacje desktopowe na Windows albo pracować w firmie .NET. Wybierz Javę, jeśli celujesz w Androida, big data albo firmę, której backend działa na JVM. Każdy z nich uczy pojęć potrzebnych w drugim: klas, interfejsów, generyków, kolekcji, wyjątków i środowiska uruchomieniowego z odśmiecaczem pamięci.