Artigos com o marcador Java

Tentando fazer o papel de advogado do diabo, repasso o interessante post de Mario Fusco. No texto ele fala de 10 razões para começar a pensar em uma linguagem que substitua Java.

“Don’t get me wrong. During my professional life I have written tons of Java code and of course I think it is a great language still. For sure it has been a great improvement from C++ and Smalltalk. But now even Java is starting to feel the weight of its 15 years.

Indeed during my experience I had to face up with some mistakes, flaws and lacks in its design and specification that made my Java programmer life less pleasant. With millions of Java programmers and billions of lines of code out in the world, I am far to say that Java is going to be dead in the near future. Anyway after the rise of some JVM compatible languages (my favorite is Scala), these issues are becoming even less tolerable and I am starting thinking that it is time to slowly move away from Java (but not from the JVM). More in detail, in my opinion, the 10 most important problems of the Java language are:

1. Lack of closure: I don’t think I have to explain this. Functional programming exists since decades, but in the last years they are gaining more and more interests, mostly because it allows to write naturally parallelizable programs. I partially agree with Joshua Bloch that underlined the problems of introducing them in Java as a second thought (the BGGA proposal was truly awful), but anyway their lack makes impossible to have any kind of real functional programming in Java.

2. Lack of first class function: this issue is in some way related to the former one but I believe it is even worse. The only way to achieve a similar result in Java is by using the ugly and sadly famous one-method anonymous inner classes, but it looks actually a poor solution. Even in C# has been provided a better one by the implementation of the delegate mechanism.

3. Primitive types: it should be beautiful if everything in Java was an Object, but they didn’t design it in that way. That leaded to some issue, like the impossibility to have a Collection of int partially resolved in Java 5 through the autoboxing feature (see below). It also generated some confusion between passing by value and passing by reference. Indeed a primitive data type is passed to a method by value (a copy of the data type is duplicated, and passed to the function) while true objects are passed by reference.

4. Autoboxing and autounboxing: this feature has been introduced in Java 5 to overcome the problems caused by the presence of primitive types. It allows to silently convert a primitive type in the corresponding object, but often it is cause of other problems. For example an Integer can have null value, but the same doesn’t apply to int, so in this case when the Integer is changed in an int the JVM can’t do anything else than throw a difficult to debug NullPointerException. Moreover it is cause of other strange behavior like in the following example where it is not so easy to understand why the test variable is false:

Integer a = new Integer(1024);
Integer b = new Integer(1024);
boolean test = a < b || a == b || a > b;

5. Lack of generics reification: generics are one of the cool features introduced with Java 5, but in order to mantain the compatibility with the older version of java they miss some important characteristic. In particular it is not possible to introspect their generic type at runtime. For example if you have a method that accepts as parameter a List<?> and you pass to it a List<String> you are not allowed to know at runtime the actual type of the generic. For the same reason you cannot create array of generics. It means that despite it looks quite natural the following statement won’t compile:

List<String>[] listsOfStrings = new List<String>[3];

6. Unavoidable generics warnings: have you ever found yourself in the impossibility to get rid of a bothering warning about generics? If you make a large use of generics like me, I bet you did. And the fact that they felt the need to introduce a special annotation to manage this situation (@SuppressWarnings(“unchecked”)) is symptomatic of the dimension of this problem and, in my opinion, that generics could have been designed better.

7. Impossibility to pass a void to a method invocation: I admit that the need to pass a void to a method could look weird at a first glance. Anyway I like DSL and while implementing a special feature of my DSL library (lambdaj) I had the need to have a method with a simple signature like this: void doSomething(Object parameter) where the parameter passed to this method is the result of another method invocation done with the only purpose to register the invocation itself and execute it in the future. With my big surprise, and apparently without a good reason, since the println method returns void, I am not allowed to write something like this:

doSomething(System.out.println(“test”));

8. No native proxy mechanism: proxy is a very powerful and widely used pattern, but Java offers a mechanism to proxy only interfaces and not concrete classes. This is why a library that provide this feature like cglib is employed in so many main stream frameworks like Spring and Hibernate. Moreover cglib implements this feature by creating at runtime a Class that extends the proxied one, so this approach has a well known limitation in the impossibility to extend and then proxy a final Class like String.

9. Poor switch … case statement: the switch … case as specified in java allows to switch only on int and (starting from java 5) enum. That looks extremely few powerful especially if compared with what offered by a more modern language like Scala.

10. Checked exception: like primitive types, checked exception have been one of the original sins of Java. They oblige programmers to do one of the following two equally horrible things: fill your code with tons of poorly readable and error prone try … catch statement where often the most meaningful thing to do is to wrap the catched exception in a runtime one and rethrow it; or blurring your API with lots of throws clause making them less flexible and extensible.

The real problem here is that the only way to fix the biggest part of the issues I mentioned is to take a painful decision and define a specification of the language that drops the backward compatibility with the current one. I guess they will never do that, even if I believe it should not be extremely difficult to write a program that allows to automatically translate the old Java sources in order to make them compatible with this new hypothetic release. And in the end, this is the reason why I decided to start looking for a better JVM compatible language.”

—

Esse post gerou uma boa discussão nos fórums do The Server Side, com um monte de gente se posicionando contra ou a favor. No meu ponto de vista, boa parte das fragilidades apontadas no texto podem ser resolvidas através de bibliotecas que estendem a linguagem. E falando francamente, não acho as alegações de Mario boas o suficiente para promover uma mudança de plataforma, principalmente quando levamos em consideração todo o legado construído na última década. Os problemas apontados por ele são reais, mas não impactam em nada na produtividade e extensibilidade das aplicações desenvolvidas em Java.

Uma das maiores reclamações da comunidade em torno de Java era que as ferramentas de desenvolvimento não seriam tão eficientes e produtivas como as encontradas para a plataforma .Net. Quem acompanhou as últimas versões do Eclipse e do Netbeans sabe que os recursos para construção de aplicações a partir de modelos ou templates já fazem parte do dia a dia de todo desenvolvedor. Para melhorar um pouco mais as coisas, novos frameworks surgem quase que diariamente com o objetivo de melhorar continuamente a maneira de desenvolver aplicações na linguagem (atualmente estou desenvolvendo meus projetos usando o Seam. Complexo e completo).

A discussão é boa, mas eu ainda pretendo investir algumas horas de meu tempo para melhorar as minhas habilidades como desenvolvedor Java. Mas como nada é eterno, não custa nada começar a olhar algumas coisas como Scala, Ruby on Rails, Grails e outras linguagens e frameworks da moda

Uma das principais reclamações de meus alunos nas disciplinas de programação da Universo e Maurício de Nassau é em relação à configuração de seus projetos web nos laboratórios das instituições. Para quem não tem notebook e depende das estações de trabalho é a mesma novela a cada aula: reconfigura o projeto para atualizar as urls’s das bibliotecas, do Tomcat, do banco, e por aí vai.

A solução mais adequada para o problema seria a utilização de um repositório de versões (CVS ou Subversion) contendo as últimas versões dos projetos, ao invés da tradicional cópia nos pendrives. Mas essa alternativa requer a disponibilidade de um servidor e a sua configuração a cada semestre para 40 ou mais alunos, além de depender da liberação de portas por conta da política de segurança de cada instituição.

Desde abril,  podemos contar com mais uma alternativa para hospedar as nossas aplicações Java: o Google App Engine. Essa nova iniciativa do Google aproveita os recursos de computação em nuvem da empresa.  Nesse ambiente, os programadores poderão contar com os recursos de uma máquina virtual Java, ambiente de deployment das aplicações e acesso aos serviços mais comuns de aplicação web, como persistência, e-mail entre outros. Os caras do Google também implementaram um plugin para o Eclipse que permite criar um projeto e fazer o deploy das aplicações diretamente nos servidores da nuvem.

Para o semestre 2009.2 eu irei preparar alguns slides sobre como usar a infraestrutura do Google, como um plano B para as estações de trabalho dos laboratórios.

Para saber mais sobre o Google App Engine, dê uma olhada nos endereços abaixo:

• Página do Google App Engine para a plataforma Java.
• Uma visão resumida das funcionalidades do GAE.
• Dicas sobre como começar um projeto com o GAE.