Java Coding Pains 19/Sep/2009
Tal como referi num artigo anterior, PolyglotProgramming: Scala, vou neste artigo enumerar as diversas “dores” que tenho sentido ao codificar sistemas em Java.
Ao contrário da minha experiência em C++, muito sustentada no facto de manter aplicações legacy em vez de desenvolver de raíz, a minha experiência com Java é menor na dimensão tempo e sustentada somente no facto de desenvolver aplicações green-field.
O sistema para qual contribuo com o papel e com as responsabilidades de senior developer é um sistema de facturação wholesale que corre em Tru64 e Windows, com base de dados em Oracle, desenvolvido em C++ com Pro*C e PowerBuilder. A sua arquictetura é como que um misto entre as arquitecturas cliente/servidor e 3-tier, se bem que a camada de lógica de negócio está espalhada pelos 3 tiers – que são dados, processos aplicacionais (servidor) e apresentação (cliente). As tecnologias que suportam o sistema, desde o sistema operativo Tru64 até às versões Oracle e PowerBuilder – entre outras situações complicadas de vendor lock-in – estão desde à muito tempo descontinuadas.
Por esse motivo, colocamos à equipa de suporte técnico (nós mesmos) o desafio de “migrar” as funcionalidades do sistema para tecnologias suportadas e modernas, mais adequadas às necessidades do negócio da facturação wholesale. E a tecnologia base de eleição foi Java, graças à soberba JVM e à API JDBC. E aqui fica o registo das vantagens de programar em Java, bem como mais abaixo as “dores” que ainda temos que procurar “curar”:
- Mecanismo de Garbage Collection, com vários modos configuráveis.
- Não é habitual ter a preocupação de passar argumentos por valor ou por referência e não nos preocupamos com lógica de ponteiros.
- Não é permitida a múltipla herança, e é habitual especificar as interfaces que ajudam a “colar” o código entre o código mais ao jeito da composição de classes do que ao jeito de herança.
- Código na vasta maioria portável entre distintos sistemas operativos, que executa sobre a soberba plataforma JVM - Java Virtual Machine.
- Cada classe é codificada num só ficheiro, de extensão “.java”.
- A ferramente de build habitual é a Ant. É muito mais simples e fácil de usar e adaptar a cada projecto do que a Make.
- Enorme comunidade de developers, com uma vasta colecção de excelentes libraries 3rd-party – a maioria sem vendor lock-in. Grandes exemplos disso são as libraries Log4J e JUnit.
- Os IDEs Eclipse e NetBeans são soberbos na ajuda que dão ao trabalho de codificação e depuração.
- A API JDBC facilita o desenvolvimento de aplicações de forma totalmente abstracta ao motor de base de dados, mediante configuração simples do driver/adapter para o motor de base de dados a usar.
- Não é habitualmente necessário uma camada extra de complexidade tal como é no caso de C++ com a STL. A linguagem Java é desde o começo muito rica.
- É unicode-ready, o que facilita a localização/internacionalização das aplicações em Java.
Mas, após as experiências com Perl e PHP e Ruby, é difícil aceitar estas “dores”:
- O código Java precisa de ser compilado para bytecode para correr sobre a JVM. Eliminiou-se o “link” mas ainda se mantém o “compile“.
- A linguagem não é puramente orientada a objectos, e permite o uso de tipos primitivos (int, long, char, ...).
- É ainda frequente ter código mais de segundo o paradigma procedimental do que segundo o paradigma orientado a objectos, o que inviabiliza o uso mais adequado da linguagem Java em sistemas onde o paradigma OOP tem diversas vantagens.
- A linguagem é estaticamente tipificada. E herdou da linguagem C e da linguagem C++ o uso frequente de casts.
- O código é ainda bastante ruidoso e com um grande nível de verbosidade. Se bem que menor do que em C++, ainda é frequente o uso e abuso da “clonagem de código”, com recurso ao copy&paste.
- A keyword final devia ser o default, em vez de ter que ser escrita explicitamente.
- Os generics requerem uma curva de aprendizagem algo inclinada.
- As anotações revelam que nem tudo está totalmente bem com a linguagem, pois tem sido hábito incrementar o conjunto de funcionalidades com recurso às anotações – meta-programming, mas sem todos os benefícios de serem pensadas de raíz coma linguagem, tal como aconteceu com generics.
- A programação concurrencial, pelo menos até à versão 7, é ainda muito complexa e difícil de ser bem implementada, sem side-effects.
Apesar destas dores, linguagens mais recentes como a Ruby e a Scala – no meu entender – ainda não estão ao nível da linguagem Java no diz respeito a manter aplicações empresariais.
- Posted in : doCoding
- Author : José Carlos Monteiro
Comments»
no comments yet - be the first?