O fim do Java e um sensacionalismo épico

Desde Agosto de 2012, temos acompanhado na mídia matérias sobre a vulnerabilidade identificada na versão de um interpretador Java para navegadores. Naquela ocasião fiz um resumo da situação para alertar os usuários de navegadores com plugin Java de como se prevenir de ataques de malwares exploradores da tal vulnerabilidade.

Após aquelas matérias iniciais bem produzidas sobre uma pesquisa corretamente coordenada, veio uma onda de sensacionalistas intitulando suas matérias com palavras como "A morte do Java" ou "O fim do Java". Veja um exemplo neste link para o artigo do IT Web.

O direito de imprensa deve ser defendido, mas profissionais mal formados e ambiciosos utilizam deste direito para o ganho de evidência e audiência a partir de calúnias de pessoas, empresas, organizações, tecnologias e qualquer outra coisa que possa ser alvo de suas ambições. Neste caso estes papagaios do mal deviam se dar conta da existência de um dever de imprensa.

O fim do Java não passa de uma especulação oportunista por causa da ameaça esclarecida em Agosto de 2012.

Quero esclarecer, tanto as matérias caluniosas quanto aqueles que detonam o Java fazem isso sem base alguma ou são atrasados mentais que acham que o mundo é Microsoft, nada contra a Microsoft. O Java não é apenas um plugin para navegadores, pois é mais do que isso.

Um leigo ou um usuário enfurecido por se sentir ameaçado pela vulnerabilidade de um plugin naturalmente pode ter uma reação contra o Java e até é compreensível tal reação. Os retardados mentais que acham que uma plataforma paga traz automaticamente segurança acabam tentando justificar seu conforto psicológico infundado com matérias como as últimas de cunho sensacionalista.

O que não pode é um blogueiro ou jornalista atacar o Java por conta de uma vulnerabilidade de um plugin para habilitar Java em navegadores. Lembro que durante a trajetória do Windows NT muitas brechas foram descobertas na segurança e expunham os seus usuários em potencial muito maior do que o problema no plugin para navegadores executarem Java a partir de sites com applets. O próprio Internet Explorer teve problemas tão grave quanto o plugin do Java para navegadores.

Não sou favorável ter Java executando em navegadores porque isso realmente sempre esteve sobre risco em seus muitos anos de existência. Esteve sobre risco não porque o plugin é falho, mas porque é uma forma de habilitar acesso maior ao computador do usuário como o acesso a seu sistema de arquivos por exemplo.

Mas isso não é problema, cada um decide se habilita ou não o plugin do Java em seus navegadores. As empresas por sua vez, devem em grande parte ter maior responsabilidade para saberem sobre as tecnologias que podem ameaçar seus sistemas e informações antes de agirem de maneira generalizada e indiscriminada por causa da sugestão errada de matérias tendenciosas ou generalistas.

A ameaça divulgada em Agosto de 2012 também não ocorre em qualquer cenário, ela depende muito de um computador desprotegido, de um usuário leigo o suficiente para não conseguir avaliar a confiabilidade de seus sites acessados e ainda estes sites terem em seus scripts aplicações Java (Java Applet). Ou seja, esta probabilidade é pequena e pode ser resolvida apenas desabilitando o plugin Java do navegador até a Oracle oficializar uma versão corretiva. Estamos o tempo todo sujeitos a ataques em nossos modens de banda larga, smartphones, sistemas operacionais, navegadores, aplicações com interação em rede, contas de email, conta em página social etc. Apesar de existir uma segurança amadurecida em todos estes itens, o ataque ainda é possível por causa de falhas humanas normalmente por parte do usuário desprevenido.

O Java utilizado pelas empresas é isolado em servidores por equipes normalmente altamente competentes em infraestruturas seguras contra ataques, tenho conferido isso em muitas das empresas para quais prestei serviços.

O conjunto de serviços Java realmente relevante não é um plugin opcional para execução de aplicações Java em navegadores, Java Applet.

Contudo, não há qualquer motivo para duvidar da segurança, integridade e capacidade do Java.

Executar linha de comando com Java

Em alguns momentos na programação, executar linhas de comandos em algum S.O. (Sistema Operacional) é uma ótima opção para interagir com seu sistema de arquivos, programas e recursos consagrados de forma direta.

Mas como fazer isso através da linguagem de programação Java?

Como uma forma segura e única para executar comando direto de um Sistema Operacional, a classe LineCommand foi criada com a função execCommand síncrona e estática.

Classe LineCommand

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class LineCommand {

    public synchronized static String execCommand(final String commandLine) throws IOException {

        boolean success = false;
        String result;

        Process p;
        BufferedReader input;
        StringBuffer cmdOut = new StringBuffer();
        String lineOut = null;
        int numberOfOutline = 0;

        try {

            p = Runtime.getRuntime().exec(commandLine);

            input = new BufferedReader(new InputStreamReader(p.getInputStream()));

            while ((lineOut = input.readLine()) != null) {
                if (numberOfOutline > 0) {
                    cmdOut.append("\n");
                }
                cmdOut.append(lineOut);
                numberOfOutline++;
            }

            input.close();
          
            result = cmdOut.toString();

            success = (p.waitFor() == 0);
          
        } catch (IOException e) {
            result = String.format("Falha ao executar comando %s. Erro: %s", commandLine, e.toString());
        } catch (InterruptedException e) {
            result = String.format("Falha ao executar comando %s. Erro: %s", commandLine, e.toString());
        }

        // Se não executou com sucesso, lança a falha
        if (!success) {
            throw new IOException(result);
        }

        return result;

    }

}

Um programador soberbo pode perguntar: Para que tanto código?

É muitos simples,  a função execCommand:

1. tem como parâmetro uma String para você informar a linha de comando;
2. a função é estática para permitir a chamada direta a partir de sua classe LineCommand;
3. é síncrona para impedir muitas interações paralelas com o S.O. caso o programador faça uma chamada recursiva acidental;
4. retorna uma String com o resultado fiél da execução;
5. tem tratamento de exceção para caso de erro nativo no comando, converte o erro para uma exceção Java para o programador capturar e tratar;
6. tem captura de erro lançado pela execução de comando incorreto.

Vamos realizar alguns testes baseado em S.O. Windows.

Testando

O código a seguir testa três situações: uma situação correta de comando, outra situação de comando correto com parâmetro inválido e por último, é executado um comando inválido. Você perceberá que todas estas situações serão compreendidas pela função.

    public static void main(String[] args) {

        String result = null;

        // Teste com comando correto
        try {
            result = LineCommand.execCommand("cmd /C dir c:");
            System.out.println(result);
        } catch (IOException e) {
            System.err.println(e.getMessage());;
        }

        // Teste com comando correto e parâmetro incorreto
        try {
            result = LineCommand.execCommand("cmd /C dir ccc:");
            System.out.println(result);
        } catch (IOException e) {
            System.err.println(e.getMessage());;
        }

        // Teste com comando desconhecido
        try {
            result = LineCommand.execCommand("go to");
            System.out.println(result);
        } catch (IOException e) {
            System.err.println(e.getMessage());;
        }
      
    }

Resultado

Após a execução, o resultado a seguir será obtido.

Teste com comando correto:
 O volume na unidade C nÆo tem nome.
 O N£mero de S‚rie do Volume ‚ 54C4-76F5

 Pasta de C:\Users\teste\workspace\DNPark

09/11/2012  17:27    <DIR>          .
09/11/2012  17:27    <DIR>          ..
13/10/2012  17:45             1.212 .classpath
28/01/2012  12:23               382 .project
13/10/2012  15:43    <DIR>          .settings
01/02/2013  00:28    <DIR>          build
20/11/2010  21:34               332 build.properties
14/10/2012  13:02             4.090 build_dnpark.xml
12/10/2012  19:50           233.857 DNPark_Nettyc.rar
09/11/2012  17:27    <DIR>          DNPark_Release
09/11/2012  17:27         4.390.741 DNPark_Release.zip
04/04/2012  12:15         2.718.075 DNPark_Release_2_1_0.rar
13/10/2012  22:27         4.228.801 DNPark_Release_2_2_0.rar
14/10/2012  20:20         4.235.275 DNPark_Release_2_3_0.rar
05/11/2012  18:30         4.240.128 DNPark_Release_2_4_0.rar
08/11/2012  12:48         4.240.244 DNPark_Release_2_4_1.rar
12/10/2012  10:57           235.820 DNPark_VersaoComandos_Modem_Tunelador.rar
12/10/2012  18:03           228.914 DNPrk_Antes_NETTY.rar
08/11/2012  12:49             7.212 HistoricoDeVersao.txt
13/10/2012  17:45    <DIR>          lib
11/01/2011  16:26                59 netpathw.bat
10/01/2011  11:49           262.427 NetPath_Kit.rar
13/10/2012  15:45    <DIR>          src
13/10/2012  15:43    <DIR>          subproject
13/10/2012  15:44    <DIR>          wrapper_WinNT
06/04/2011  12:22           141.017 wrapper_WinNT.rar
              17 arquivo(s)     25.168.586 bytes
               9 pasta(s)   18.772.152.320 bytes dispon¡veis


Teste com comando correto e parâmetro incorreto:
 O volume na unidade C nÆo tem nome.
 O N£mero de S‚rie do Volume ‚ 54C4-76F5

 Pasta de C:\Users\teste\workspace\DNPark


Teste com comando desconhecido:
Falha ao executar comando go to. Erro: java.io.IOException: Cannot run program "go": CreateProcess error=2, O sistema não pode encontrar o arquivo especificado

 Até breve.