C# vs Java: sintaxis, runtime, genéricos, LINQ y cuál aprender

C# y Java son parientes cercanos. Los dos son lenguajes con tipado estático, orientados a objetos, con recolector de basura y sintaxis de estilo C; los dos compilan a bytecode para una máquina virtual, y los dos se usan para grandes sistemas de backend. C# se publicó en 2002 en parte como la respuesta de Microsoft a Java, y a lo largo de dos décadas se han ido tomando características el uno del otro (lambdas, genéricos, records, pattern matching). Quien conoce uno puede leer el otro casi de inmediato.

Las diferencias que importan en el día a día son más pequeñas y más concretas. Esta página las recorre con código: fragmentos de C# que puedes ejecutar y Java en bloques estáticos para comparar.

De un vistazo

Sintaxis: casi igual

Las clases, los métodos, if, for, while, switch y try/catch se leen de forma casi idéntica. Las diferencias visibles son las convenciones de nombres y unas pocas palabras clave: los métodos de C# van en PascalCase (ToUpper, WriteLine) y los de Java en camelCase (toUpperCase, println); C# escribe string y bool, Java String y boolean; la herencia es class Dog : Animal en C# y class Dog extends Animal en Java.

// 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());
        }
    }
}

Salida:

ANA
BEN

Además, C# compara los strings por valor con ==, lo que elimina uno de los bugs clásicos de principiante de Java: en Java, == sobre dos objetos String compara referencias, así que dos strings iguales construidos en tiempo de ejecución (leídos de la entrada, concatenados) pueden resultar distintos.

Propiedades en lugar de getters y setters

Las clases de Java exponen su estado mediante métodos getName() y setName(), normalmente generados por un IDE o por Lombok. C# tiene propiedades: miembros que se leen como campos pero ejecutan código.

// 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}");
    }
}

Salida:

Mug: 9.50

El inicializador de objetos new Product { Name = ..., Price = ... } asigna propiedades justo después de la construcción. Los records de Java (Java 16) cubren el caso de los datos inmutables; C# también tiene records (C# 9), y además propiedades para todo lo demás.

Tipos de valor: structs

En Java, todo tipo definido por el usuario es un tipo de referencia guardado en el heap; solo los ocho tipos primitivos (int, double, ...) son valores. C# te permite definir tus propios tipos de valor con struct. Un struct se copia al asignarlo y puede vivir en línea dentro de arrays y otros objetos, sin una reserva aparte en el heap.

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);
    }
}

Salida:

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

Esto importa en los juegos y en el código numérico, donde millones de objetos pequeños presionarían al recolector de basura. Consulta structs.

Genéricos: reificados frente a borrados

Java borra los argumentos de tipo genéricos en tiempo de compilación: en tiempo de ejecución, una List<Integer> es solo una List, y List<int> no está permitido (obtienes objetos Integer con boxing). C# conserva los argumentos de tipo en tiempo de ejecución, así que List<int> guarda ints en bruto y el código puede preguntar qué es 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);
    }
}

Salida:

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

typeof(T) y new T() funcionan porque el runtime conoce T. En Java los dos son errores de compilación, y la solución habitual es ir pasando un objeto Class<T>.

LINQ frente a streams

Los dos lenguajes tienen una API fluida para filtrar y transformar colecciones. La de Java es la API de Streams (Java 8); la de C# es LINQ (C# 3), que además tiene una sintaxis de consulta y funciona contra bases de datos mediante 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}");
    }
}

Salida:

Lamp, Chair
Total: 126

Las operaciones se corresponden una a una (filter es Where, map es Select, collect(toList()) es ToList()), y las versiones de C# no necesitan stream() ni un collector. Los objetos new { Name = ..., Price = ... } son tipos anónimos, que no tienen un equivalente directo en Java.

Async y concurrencia

C# introdujo async/await en 2012: un método async devuelve un Task, y await lo suspende sin bloquear un hilo. JavaScript, Python y Rust adoptaron después las mismas palabras clave. Java tomó otro camino: cadenas de CompletableFuture y, desde Java 21, hilos virtuales que abaratan el código bloqueante normal.

// 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()));
}

Los dos enfoques escalan a muchas peticiones concurrentes. C# hace visible la asincronía en las firmas de los métodos; Java la esconde en el runtime.

Excepciones, operadores y diferencias menores

• Excepciones comprobadas. Java obliga a un método a declarar o capturar ciertas excepciones (throws IOException). C# no tiene excepciones comprobadas.
• Sobrecarga de operadores. C# permite que los tipos definan +, ==, < y compañía, y por eso la aritmética de decimal y DateTime se lee con naturalidad. Java no (BigDecimal.add).
• Virtual por defecto. Los métodos de Java pueden sobrescribirse salvo que se marquen como final; los métodos de C# deben marcarse como virtual para poder sobrescribirse, y la sobrescritura debe decir override.
• Métodos de extensión. C# puede añadir métodos a tipos existentes ("text".IsPalindrome()); Java no.
• Tipos de valor nullable. int? en C# es un int que puede ser null; Java usa el Integer con boxing.
• Tipos sin signo. C# tiene uint, ulong, ushort y un byte sin signo; el byte de Java tiene signo y, aparte del char de 16 bits, no tiene tipos enteros sin signo.

Ecosistema, empleo y cuál aprender

El ecosistema de Java es mayor en el mundo del servidor de código abierto: Spring, Kafka, Spark, Hadoop, Elasticsearch y la mayoría de los proyectos de Apache están en Java. Las aplicaciones de Android se escriben en Kotlin o Java. C# tiene la pila más integrada: un solo proveedor mantiene el lenguaje, el runtime, el framework web (ASP.NET Core), el ORM (Entity Framework) y el IDE principal (Visual Studio), y Unity lo pone en el centro del desarrollo de videojuegos.

Los dos lenguajes tienen grandes mercados laborales, y el equilibrio entre ellos depende de la región y del sector. C# es fuerte en empresas basadas en Microsoft y Azure, en software financiero y sanitario y en estudios de videojuegos.

Elige C# si quieres hacer juegos en Unity, crear aplicaciones de escritorio para Windows o trabajar en una empresa .NET. Elige Java si apuntas a Android, al big data o a una empresa cuyo backend corre sobre la JVM. Cualquiera de los dos enseña los conceptos que necesitas para el otro: clases, interfaces, genéricos, colecciones, excepciones y un runtime con recolector de basura.