Um outro assunto que tem aparecido com cada vez mais frequência na lista interna da Caelum são as diversas linguagens que rodam sob a JVM. Sejam elas compiladas diratamente para bytecode Java, ou interpretadas através da Java Scripting API adicionada no Java 6.

O Fábio Kung fez no início do ano um acalorado post intitulado 2009 o ano do Ruby on Rails no Brasil, e podemos ir além: diversas linguagens que não fazem faziam parte do mainstream corporativo vem ganhando muita força por todos os lugares.

Martin Fowler fez um trabalho minucioso em suas considerações ao uso de Ruby pela ThoughtWorks (traduzido pelo Fábio Akita aqui). Fowler discorre a respeito das opiniões e sentimentos dos lideres técnicos de cada projeto que optou por Ruby, e poucos deles (5 de 41) disseram que Ruby foi a escolha errada.

Mas será que apenas o Ruby tem ganho toda essa notoriedade e força?

O Rafael Ferreira compartilhou comigo recentemente um excelente artigo que discute os diferentes paradigmas de programação, citando vantagens e desvantagens, culminando na importância do aprendizado de diferentes linguages, em especial para tirar proveito das que facilitam o desenvolvimento de sistemas com muita concorrência.

O Renato Lucindo me mostrou também o quão grande tem sido a repercussão do Scala em grandes ambientes, como é esse caso da Électricité de France Trading que trocou 300 mil linhas de Java por Scala.

Vale também citar a troca de linguagens num dos cursos mais famosos de computação do mundo: o Structure and Interpretation of Computer Programs, curso que inicia os graduandos de ciência da computação e engenharia elétrica do MIT. Este curso foi sempre famoso por ser ministrado em Scheme, e agora depois de uma série de debates e justificativas, foi reformulado usando Python, novamente sem usar uma das linguagens enterprisey.

Pedro Matiello, que trabalha aqui com a gente, é o lider de desenvolvimento da biblioteca python-graph, que implementa diversos algoritmos para grafos em python e possui colaboração dos mais variados países.

Aqui na Caelum, além de usarmos extensivamente Ruby e Rails em projetos e termos estendido o tempo do nosso curso RR-11 para 32 horas ja há algum tempo, há um pedaço de um sistema desenvolvido em Scala e ainda temos o curso de Lógica de Programação é realizado em grande parte com Groovy.

São muitos meus amigos e colegas de trabalho estudando LISP, Erlang, OCaml, Scala e outras linguagens, sem contar Ruby/Rails e Python/Django. Todas essas linguagens podem de certa forma rodar sobre a JVM. É um lugar-comum (e é uma das dicas do excelente Pragmatic Programmer) dizer que devemos aprender mais linguanges de programação para ampliar nossa visão e formas de ataque a um problema. Já disse Peter Norvig que é necessário 10 anos para que adquiramos fluência numa linguagem de programação, mas sempre há o momento de começar.

E você? Como está seu contato com essas linguagens? Sua empresa está usando algo “novo” em seus projetos?

A lista de emails interna de desenvolvedores da Caelum sempre foi muito ativa, e ultimamente anda aparecendo alguns dos clássicos Java Puzzlers para serem debatidos. O Márcio Hasegawa recentemente postou o problema mais recente da Java Specialists Newsletter:

Problema

Por que isso dá OutOfMemoryError? Repare que criamos duas arrays que gastarão mais da metade da memória que temos, porém a primeira pode (?) ser captada pelo garbage collector, já que seu escopo termina logo:

class JavaMemoryPuzzle {
  private final int dataSize = (int)
    (Runtime.getRuntime().maxMemory() * 0.6);

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }

    byte[] data2 = new byte[dataSize];
  }

  public static void main(String[] args) {
    JavaMemoryPuzzle jmp = new JavaMemoryPuzzle();
    jmp.f();
  }
}

Já esse código, com um pequeno int i = 0 no meio, roda sem estourar a memória:

class JavaMemoryPuzzlePolite {
  private final int dataSize = (int) 
    (Runtime.getRuntime().maxMemory() * 0.6);

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }

    int i = 0;
    
    byte[] data2 = new byte[dataSize];
  }

  public static void main(String[] args) {
    JavaMemoryPuzzlePolite jmp = new JavaMemoryPuzzlePolite();
    jmp.f();
    System.out.println("sem OutOfMemoryError");
  }
}

Solução

O Sérgio Lopes respondeu na lista de maneira muito apropriada. Utilizou o bytecode para justificar o comportamento do garbage collector. Vou parafrasea-lo a partir daqui:

Se você olhar o bytecode gerado dá pra ver a diferença (javap -c Puzzle). A versão sem declaração do int gera:

   0: aload_0
   1: getfield #24; //Field dataSize:I
   4: newarray byte
   6: astore_1
   7: aload_0
   8: getfield #24; //Field dataSize:I
   11: newarray byte
   13: astore_1
   14: return

Vemos que no 6 ele guarda a referência do primeiro array (astore) na variável local _1 e depois ele cria o novo array na 11 (newarray). O problema é que a variável _1 ainda se referência para a primeira array, impedindo que o GC colete-a! Apenas depoisde já ter instanciado a segunda array ele guardará essa referência na mesma posição de variável local (_1). Nesse caso já é tarde demais e o heap estourou.

O bytecode da versão que não estoura é parecido, porém mostra a variável local int i = 0 “reutilizando” o espaço da referência a primeira array e, portanto, liberando o objeto referenciado anteriormente naquela posição para uma possível coleta:

   0: aload_0
   1: getfield #24; //Field dataSize:I
   4: newarray byte
   6: astore_1
   7: iconst_0
   8: istore_1
   9: aload_0
   10: getfield #24; //Field dataSize:I
   13: newarray byte
   15: astore_2
   16: return

Reparem que em 6 ele guarda a referência ao array na variável de posição _1 e depois ele guarda int (que vale 0, valor empilhado por iconst_0) na mesma posição (linha 8), “reutilizando” o espaço da variável antes de criar outro array gigante. Nesse caso, a referência ao segundo array é colocada na variável local _2 (linha 15).

Moral da história: só teremos liberadas as variáveis locais quando o método acaba e não quando os escopos acabam, mas o compilador pode “sem querer” liberar algumas no meio do caminho caso vá usar mais variáveis, reutilizando espaços não mais utilizados. Interessante!