`Public static void main(String[] args)` morreu

• Agora, o primeiro programa em Java não precisa mais começar com public static void main(String[] args), podendo ser escrito com a sintaxe simplificada void main()
• Na nova sintaxe, é possível lidar com entrada e saída com chamadas simples como IO.readln e IO.println, tornando o código muito mais intuitivo
• Construções verbosas como new Scanner(System.in) e System.out.println deixam de ser necessárias
• O incômodo de tantos anos “finalmente acabou”; agora, com a estrutura básica do Java mais leve, a barreira de entrada diminui e a facilidade de aprendizado deve melhorar bastante

---

• Tradicionalmente, o Java exigia a longa declaração public static void main(String[] args) para iniciar um programa
• Porém, em 16 de setembro de 2025, a declaração complexa da função main, considerada o primeiro exemplo mais básico de Java, foi substituída por uma nova forma simplificada
• Forma antiga:

  public class Main {  
      public static void main(String[] args) {  
          Scanner scanner = new Scanner(System.in);  
          System.out.print("What is your name? ");  
          String name = scanner.nextLine();  
          System.out.println("Hello, " + name);  
      }  
  }  
  

• Nova forma:

  void main() {  
      var name = IO.readln("What is your name? ");  
      IO.println("Hello, " + name);  
  }  
  

• Havia críticas de que era uma sintaxe desnecessariamente verbosa para iniciantes, algo que precisava ser decorado como uma “fórmula mágica”
• Ao eliminar a complicação e a dificuldade de entendimento da declaração antiga e introduzir uma sintaxe concisa, a legibilidade do código melhorou e a barreira de entrada para começar em Java caiu bastante
  • Exemplos básicos não precisarão mais usar criação de objetos e chamadas complexas como Scanner e System.out.println

Good Fucking Riddance = “Ainda bem que isso sumiu de vez. Tchau e bença”

[kayws426]

Parece como dizer que, só porque surgiu um novo jeito, o método antigo morreu.
Isso realmente significa que o método antigo não pode mais ser usado e que é obrigatório usar o novo?

[jhk0530]

Uau

[jwh926]

Preciso reaprender Java..

[carnoxen]

O main morreu. Vida longa ao main!

[GN⁺]

Comentários do Hacker News

• Vou sentir falta desse processo de, com o tempo, ir entendendo esses trechos de código estranhos. Quando aprendi Python primeiro e depois fui para Java, eu achava curioso não saber o que tipos como void ou String[] significavam. Depois que aprendi tipos, entendi isso; em seguida, entendi os conceitos de classe e objeto, e por que main existe como método static. Indo mais fundo, aprendi até quando essa classe é chamada, e aquele código que no começo parecia só boilerplate foi começando a fazer sentido. Imagino que um desenvolvedor Java mais experiente consiga extrair ainda mais significado dessa única linha do que eu. Ainda assim, é um alívio que isso tenha sumido agora

  • É realmente um alívio. Nos últimos 30 anos, o ensino de software vem ensinando desenvolvedores, em nome da "engenharia", a produzir complexidade desnecessária. Por exemplo, o desenvolvedor A cria classes para tudo que precisa, seja ponto de entrada, callback, interface ou o que for. Como resultado, passamos a ter classes. O desenvolvedor B adiciona variáveis de instância às classes e torna tudo mutável, formando um "lamaçal de implementação". Depois, outro desenvolvedor adiciona herança para reutilizar código, o que gera ainda mais complexidade e pesadelos de despacho dinâmico. No fim, surgem ciclos de referência (rference cycle) e as relações entre os objetos ficam todas emboladas. Com o tempo, refatorar vai ficando cada vez mais difícil e cansativo, até que no fim se apaga tudo e se recomeça do zero

  • Lembro de, quando aprendi programação pela primeira vez na faculdade, olhar esse código e o professor dizer: "normalmente eu explicaria tudo no código, mas essa parte vocês só aceitem por enquanto". Mais tarde, quando percebi que eu entendia completamente aquele código, foi uma experiência bem legal. Mesmo assim, parece que os tempos estão mudando, e isso dá uma sensação de alívio

  • Na prática, métodos de classe static são quase uma negação da realidade de que o ponto de entrada único de um programa não precisa necessariamente estar ligado a uma classe. Há linguagens, como C++, Python e Ruby, que reconhecem essa realidade procedural, mas o Java parece querer vendar os olhos do usuário e empurrá-lo para um "mundo OOP perfeito"

  • Para quem conhecia o estilo antigo baseado em class, o novo estilo (como unnamed classes do Java 21) parece levantar ainda mais perguntas. Fico me perguntando se isso realmente transformou o Java, o idioma de "tudo é objeto", em uma linguagem procedural. Por exemplo, se forem necessários argumentos de linha de comando, como isso funciona? Eu normalmente evito Java e não sei muito sobre isso, mas essa é uma dúvida sincera

• Na época do Java 1.2, a leitura da entrada padrão era feita assim. A classe Scanner ainda é novidade para mim, então ela parece estranha

BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
String input = in.readLine();

• Tive uma experiência parecida. Como trabalhei com Java há muito tempo, o padrão public static void main me era familiar, mas o uso de Scanner parecia estranho e eu nunca tinha entendido exatamente por quê

• Pela minha experiência, como trabalho há décadas em projetos grandes, a forma como a função main é escrita não afeta em nada meu dia a dia nem minha carreira. Fico curioso sobre o quanto essa mudança realmente impacta na prática

  • Se você for desenvolvedor Android, o conceito de main nem existia. Sinceramente, não acho que o fato de a implementação de um Hello World trivial ser feia seja uma boa medida para saber se a linguagem lida bem com coisas mais complexas

  • Muita gente começou a programar em Java digitando main dezenas de vezes sem ter a menor ideia do que aquilo significava

  • Para desenvolvedores profissionais, o impacto é pequeno, mas para iniciantes isso é importante. Eu já ensinei Java, e antes de imprimir "Hello, World" os alunos tinham que decorar uma fórmula mágica (boilerplate), o que acabava funcionando como barreira de entrada

  • Pode ter impacto se você estiver criando uma interface de linha de comando, mas não é tão comum fazer CLI em Java

  • Nos últimos cinco anos, eu não me lembro de ter visto main em nenhuma codebase. E, em vez de criar classes novas diretamente, na maioria das vezes você implementa ou estende classes específicas de algum framework

• JEP 445: Unnamed Classes and Instance Main Methods foi lançado no Java 21
  https://openjdk.org/jeps/445

  • É uma pena que esse recurso tenha sido lançado de forma a só poder ser usado em programas de arquivo único. Se permitissem métodos em nível de pacote ou colocar várias classes/records em um arquivo, acho que o Java teria ficado melhor. Mas, de qualquer forma, parece que eles não queriam impacto em "como o código Java é geralmente escrito"

• É impressionante ver o Java finalmente evoluindo, depois de 30 anos, para uma linguagem bem razoável

  • Eu escrevi muito código puramente em Java e C++, sem framework, e nessa época havia bem menos boilerplate e tudo era mais simples. A primeira vez que senti uma conveniência de verdade foi quando lambdas foram adicionadas, uns 10 anos atrás. Depois da introdução de lambdas, senti o código ficar menor e muito mais agradável. Durante muito tempo, Java foi absurdamente explícito, com muita repetição desnecessária, como se até nas coisas triviais ele servisse só para checar erro de digitação. O clima era esse até o Kotlin ganhar força; depois, com lambdas e classes anônimas, a experiência de desenvolvimento melhorou bastante

  • Dizer que Java era uma linguagem horrível é um grande exagero

  • Por outro lado, acho que linguagens como Python continuam desconfortáveis mesmo depois de 30 anos

  • Imagino que você nunca tenha experimentado uma linguagem realmente ruim, ou então seu padrão para "não é horrível" é muito alto

  • Ainda assim, é admirável que Java tenha uma compatibilidade retroativa excelente e um sistema de gerenciamento de pacotes

• Isso foi mencionado em um comentário anterior, mas como desenvolvedor Java, Python me parece mais estranho, embora eu não ache que o jeito atual seja ruim. Ainda assim, se alguém começa a programar sem entender os fundamentos da abstração, talvez Java não seja a melhor escolha para "introdução à programação". Quando uma ferramenta é projetada orientada a objetivo, paradigma etc., às vezes acaba havendo abstrações extremas. Como Java foi projetado com foco em OOP, faz sentido pensar naturalmente em blocos como interfaces. Os modificadores de acesso de métodos/classes também são claramente separados de acordo com para quem servem (public, protected, default, private etc.). Ou seja, a entrada no Java começa pela exposição da interface voltada ao usuário (o programador). Pode parecer estranho, mas pelo menos é consistente

  • Sintaxe pesada não tem relação direta com OOP. Nenhuma definição de OOP antes do surgimento do Java dizia que "funções não podem existir fora de classes". A Sun rejeitou por muito tempo o conceito de funções independentes (static import só veio no Java 5, closures no Java 8, compact source files/instance main só agora), e o resultado é que todas as funções ainda ficam dentro de classes (por pragmatismo e compatibilidade, não por motivo filosófico). Tentou insistir em "tudo é objeto", mas ao mesmo tempo criou a contradição de introduzir valores primitivos. Não há vantagem prática em exigir que funções estejam dentro de classes. Na verdade, teria sido melhor poder definir métodos em valores como inteiros. Aliás, em linguagens "puramente OOP" como Smalltalk, você pode definir funções livremente fora de classes e executar código diretamente no REPL
    Link relacionado

  • Hello World é importante porque consegue mostrar ao mesmo tempo o boilerplate necessário para executar um programa e o código real que faz a saída. Além disso, do ponto de vista da configuração das ferramentas de build, parte disso não é exatamente 'boilerplate', mas sim procedimento de prática/configuração de ferramentas. Se isso for explicado de cara, não é um grande problema

• Se o compilador estiver só fazendo um truque interno para gerar uma classe, então isso é apenas uma mudança cosmética. Se outras funções de nível superior não forem permitidas, continua sendo só um caso especial esquisito

  • C# oferece suporte a top level statements desde a versão 9.0, mas no fim isso também é convertido internamente em métodos estáticos. Várias funções top level funcionam de forma parecida. Exemplo real: C# decompiled example
    Esses truques são, na prática, exemplos de transformações úteis de compilador (closures, async state machine etc.). Essa mudança entra na mesma categoria

  • Em C/C++, o fato de só em main() se aplicar o return 0 implícito também parece uma esquisitice parecida

  • Se apenas main puder existir como função top-level e nada mais, também não acho que isso seja uma mudança muito boa

• Não entendo por que exemplos de código Java omitem as linhas de import. Se querem mostrar a complexidade do boilerplate, parece que import também deveria aparecer obrigatoriamente

  • Normalmente a IDE gerencia os import automaticamente, então ninguém liga muito para isso. No caso de classes relacionadas a IO, em exemplos compactos nem é preciso import, então o código realmente funciona daquele jeito

  • A maioria das IDEs Java gerencia import automaticamente

• Se abstraíssem o ponto de entrada public static void main(String[] args) para o paradigma de top-level statements como no C#, parece que isso reduziria o boilerplate e deixaria o código mais conciso. Fico curioso por que não fizeram isso

  • Recomendo ler o documento Paving the on-ramp

  • Se o ponto de entrada existe como um caso especial de exceção, então isso já é reconhecer os limites do OOP. Nesse caso, talvez fosse melhor desenhar com coragem uma nova alternativa

• Acho interessante que a abordagem de unnamed class facilite implementar variáveis globais, permita hot reload e deixe a sintaxe mais concisa. Por outro lado, como arquivos Java têm a restrição de precisar ter o mesmo nome da public class, talvez bastasse tornar a parte public class X { } opcional e só usar quando necessário. Não entendo muito bem por que precisaram introduzir classes sem nome
  O compilador continua transformando isso em uma classe como HelloWorld.class, então esse nome é só um detalhe de implementação e não pode ser usado diretamente no código-fonte
  https://openjdk.org/jeps/445