paulo1205
(usa Ubuntu)
Enviado em 30/07/2015 - 12:16h
Você tem de tomar cuidado com algumas lendas que se dizem por aí. Algumas perduram de coisas que já foram mais ou menos verdadeiras um dia, e muitas são e sempre foram simplesmente falsas.
Quando Java foi criada, ela foi claramente e declaradamente inspirada no C++. Ela também foi projetada para ser mais simples, deliberadamente omitindo alguns recursos de C++ (tais como ponteiros, herança múltipla e programação genérica), implementando algumas ideias semelhantes àquilo que se fazia em C++ com formatos diferentes (tal como a declaração de
interfaces em vez de classes abstratas), e liberando o usuário de gerir memória por conta própria (ao implementar forçosamente um
garbage collector). Ainda na linha de ser mais simples, Java optou por não ser multi-paradigma como C++, mas por permitir somente programas orientados a objeto.
De cara, já há algumas mentirinhas mesmo nas promessas originais. A mais séria, para mim, é que, em vez de acabar com ponteiros, Java transformou todos os objetos necessariamente em ponteiros. Usuários básicos podem nem sempre se dar conta disso, mas alguns comportamentos estranhos, principalmente do ponto de vista de quem já trabalhou com outras linguagens, se devem justamente a essa característica interna. Para não escancarar o engodo, o pessoal de Java usa o nome alternativo, mas praticamente sinônimo, de “referências” (o que, por si só, é outra infelicidade, pois as referências de Java são diferentes daquilo que o C++ já chamava pelo mesmo nome).
De 1995 para cá houve muitas mudanças, tanto no mundo de Java quanto no de C++. As duas linguagens cresceram muito. O C++ já era grande e, com as atualizações do padrão dos últimos anos, está maior ainda. Mas o Java, que já se gabou de ser simples, é hoje muito mais complexo do que aquela linguagem original, principalmente quando usado com recursos do JEE. Curiosamente, uma parte significativa do crescimento do Java foi reincorporando, com diferentes graus de adaptação, recursos do mundo C++ que tinham ficado de fora das primeiras versões justamente por serem alegadamente complicados demais (como programação genérica, para citar um exemplo).
(Nunca medi objetivamente, mas tenho o sentimento de que, em termos relativos, o fator
bloat, dado pela relação “tamanho de hoje”/“tamanho em 2000” (ou qualquer outra data), é capaz de ser maior em Java do que em C++.)
Do ponto de vista de modelagem e projeto de software orientado a objetos, Java não tem absolutamente nenhuma vantagem sobre C++. Nem poderia ter, visto que optou por oferecer apenas um subconjunto do que C++ já oferecia no início da década de 1990. Pelo lado positivo, teoricamente Java tem a vantagem de impedir desvios do modelo estritamente orientado a objetos. Na prática, contudo, há categorias de problemas que não têm ganho nenhum com OOP. Além disso, há formas de transformar Java noutra coisa que não puramente OOP (por exemplo: uma classe com todos os membros públicos e todos os métodos estáticos, ou socando uma tripa gigantesca de código dentro de um mesmo método). Como já antevia um certo
paper de caráter majoritariamente humorístico, mas nem por isso privado de dizer sérias verdades, “
Real Programmer can write FORTRAN programs in any language”. Java não é exceção, mesmo sem ter um
goto que funcione (a palavra-chave está lá, reservada, mas seu comportamento (ainda) não foi definido).
A “grande vantagem” de Java sobre C++, tal como sempre alardeada por seus proponentes, é sua menor propensão a falha por causa erros cometidos pelo programador ao lidar com alocação dinâmica de memória. De fato, quando Java foi criada, eram muito comuns os problemas causados por erros ao se trabalhar com ponteiros para dados alocados dinamicamente. Era comum o erro de esquecer de liberar um certo dado, ou o de liberá-lo prematuramente, enquanto ainda havia outras partes do programa apontando para ele, ou ainda o de liberar o mesmo ponteiro mais de uma vez, com consequências indefinidas. Ao transformar todos os dados (incluindo alguns para os quais isso não faria sentido, mas não vou me estender sobre isso agora) em ponteiros controlados exclusivamente e internamente pelo ambiente de execução, programadores Java só precisariam dizer a partir de quando usar um dado, e o próprio ambiente se encarregaria de liberar aquele dado num momento em que a liberação fosse possível e conveniente. Não tendo de se preocupar em codificar o tratamento de cada ponteiro, e principalmente por não ter de gastar tempo procurando problemas quando alguma coisa não ia bem com o tratamento de memória, teoricamente os programadores poderiam se concentrar mais naquilo que seus programas teriam de entregar, e isso permitiria um tempo mais rápido de desenvolvimento para grandes projetos.
Essa ideia ajudou bastante a vender o Java. Grandes empregadores gostam de poder vender prazos mais curtos (nada de deixar a equipe confortável!; se a ferramenta ajuda a diminuir a quantidade de trabalho do “colaborador”, então que se diminua o tempo que ele tem para realizá-lo!) e gostam de pagar salários mais baixos (ainda mais se os “colaboradores” precisarem de menos qualificação e experiência).
Curiosamente, a “grande vantagem” sobre C++ também se baseou em algumas falácias e ajudou a produzir outras. Para desfazer tais mitos, acho interessante saber, entre outras coisas, que:
1) A comparação foi injusta desde o início. Os problemas com ponteiros experimentados na década de 1990 eram sobretudo em programas em C puro (não C++), ou em programas em C++ mal-escritos (i.e. escritos sobretudo ao estilo do C, sem se beneficiar realmente de recursos e técnicas disponíveis em C++).
2) A técnica de RAII (
Resource Acquisition Is Initialization) já havia sido desenvolvida na década anterior, e justamente no mundo C++. Se utilizada a técnica como padrão de projeto, a maior parte dos problemas com alocação de memória seria simplesmente evitada.
3) Ao contrário de
garbage collection, RAII serve para qualquer tipo de recurso, não apenas para memória. Com RAII bem feito, um programa C++ pode adquirir e liberar no momento adequado tanto memória quanto
sockets de comunicação via rede, descritores/tratadores de arquivos,
locks em arquivos ou registros de bancos de dados, presença de determinados arquivos ou diretórios em disco, ou qualquer outro tipo de recurso que o ambiente oferecer ou mesmo que você inventar.
4) Ao esvaziar e desestimular o uso de destrutores, Java simplesmente impediu a implementação de RAII em programas em Java.
5) Programadores ruins, do tipo que não seriam competentes para liberar memória no momento certo, acabam não sendo competentes para lidar com outros recursos. Qualquer administrador de sistemas que lide com suporte a ambientes Java (Tomcat, JBoss, Weblogic, Websphere etc.) já viu a situação de ter centenas de
sockets de rede que ficam indefinidamente presos, simplesmente porque o código cliente nunca se preocupou em fechá-los, possivelmente porque os programadores nem sabem que têm de fazê-lo.
6) Muita gente acha que
garbage collection serve apenas para não precisar liberar explicitamente memória, quando, na verdade, essa é
somente uma consequência do objetivo real, que é o de
simular memória infinita. O perigo de quem se acostuma a pensar com memória infinita é esquecer que está trabalhando com um computador real, em que todos os recursos, inclusive a memória, são finitos.
7) Por isso mesmo, até no que diz respeito somente a memória, qualquer administrador que lide com suporte a ambientes Java já viveu a situação de ter de fazer o “
reboot profilático” ou “periódico” (se não de todo o servidor, ao menos da JVM, e com frequência que pode ser semanal, diária, ou até mesmo horária, dependendo do caso) apenas para limpar o ambiente da JVM, cujo consumo de memória médio cresce indefinidamente ao longo do tempo, até congelar o ambiente por conta de uma aplicação que vai gerando objetos intrincados e interdependentes, que o
garbage collector não sabe como limpar.
8) Quem nunca viu um “
null pointer exception” em Java (note a ênfase em “
pointer”)? Como assim, se a linguagem sempre se vendeu como não tendo ponteiros?
---
Se você estiver de olho só na quantidade de vagas no mercado de programadores Java (com os salários ridículos por ele pagos a tais profissionais), vá de Java (ou não -- existe mercado para .NET também, e C# com .NET ainda é melhor do que Java com JEE). Se quiser aprender algo melhor e mais profundo, não tem o que pensar: C++ é o que há.
