Michael Nascimento Santos's Blog

Porting Archives

Bitten by the class literal change in Tiger

If you are a returning reader, you're probably aware of the enum implementation I wrote for Java 1.4 almost three years ago. Running some Java 1.4 compatible code compiled with Java 5 has just called my attention to a supposedly low impact change that was implemented in Tiger.

Since Java 5, a class literal, i.e., an expression such as MyClass.class does not trigger class initialization anymore. This is a well known, documented issue, but solutions are not clean nor cover all previously supported scenarios.

Let me explain how my enum implementation is affected by this bug so you can understand if this bug might affect your Java 1.4 code. Enum's sole constructor registers the newly created instance's in a few internal Map cache structures. I mean, when something like this is executed:

public final class MyEnum extends Enum {
   public static final MyEnum A = new MyEnum("A");
   public static final MyEnum B = new MyEnum("B");

   private MyEnum(final String name) {
      super(name);
   }
}

, cache is populated to tell what is the domain for MyEnum (A and B) and to be able to tell you that the instance that represents the String constant "A" in runtime for MyEnum is MyEnum.A

Ok, now that we have a real world example, let's see what worked with Java 1.4 and fails with Tiger and Mustang:

MyEnum m = (MyEnum)Enum.get(MyEnum.class, typedValue);

With Java 1.4, it works; with Java 5, you will get null. The reason is simple: A and B are never instantiated because the class is never initialized.

Now, to the shocking news: there is no way to tell whether a Class instance has been initialized nor a 100% reliable way to force it to initialize. Workarounds such as:

Class c = MyEnum.class;
Class.forName(c.getName(), true, c.getClassLoader());

will require you to handle an exception that should never been thrown in this situation (ClassNotFoundException) and will fail if c.getClassLoader() == null and your code haven't been granted the RuntimePermission("getClassLoader") permission.

Therefore, I've submitted a RFE to add Class.initialize() and Class.isInitialized() to Java SE. I really would like to see this implemented for Java SE 6, but I think it will have to wait for Java 7. This change involves messing with shared native C code and refactoring a lot of stuff on the way, so you are welcome to help me in this task in the JDK Collaboration project.

For now, beware of code that relies on class literal triggering class initialization and hope the ugly workaround above works for you if you cannot avoid it.

The language barrier

Have you imagined how hard it would be to learn and to program in Java if all language keywords, all docs, all things related to Java were written in Klingon? Well, for those who cannot read in English, this is called daily life (those who understand Klingon are not my target audience here).

Most of the talented, gifted young programmers I have known had no clue about English when I first met them. Once you started working with them, you would realize they had't made much progress yet not due to some technical limitation, but rather due to the language barrier. Java keywords made no sense to them, so things that should be natural were hard to learn. Class and method names didn't convey any idea about what they did; they were just hard to memorize. When it came to Javadocs, well, they were just useless. They had to rely on other people's experience and bad translation software to learn about bleeding-edge technology and frameworks. Basically, there were only two possible "happy" outcomes for their situation: either they met a smart senior developer who was able to read in English and that became their mentor or they ended up learning the language, what took several months at best and was not a viable option to all, since some of them did not have the same talent for learning "real" languages or simply couldn't afford a English course (which was needed for some of them).

All this wasted potential has just one cause: the language barrier. It is not really fair to expect people to learn another language in order to become good developers. Learning English and a programming language require very different skill sets and not everyone has both of them. However, this is actually what we expect from these young talented folks. And unfortunately, given our current reality, it is reasonable. After all, how are they supposed to evolve (and to survive) unless they can learn on their own? Hopefully, it seems this situation may change in the near future.

Although we shouldn't expect for a translated version of the Java programming language (nor we would want it, actually), more resources should be available to non-English speakers and, as far as I can tell by observing a few initiatives in the Brazilian community, both the community and Sun care about this issue and are trying to address it.

Recently Sun has provided support (including tools and legal arrangements) to allow volunteers to translate Javadocs to their native language. The Brazilian Portuguese Javadoc translation project, jdk5-api-pt-br.dev.java.net, has already made its first release available . Of course there is still a lot of work to be done in order to have a fully translated copy available and that the need to sign an agreement certainly keep some people away from the effort, but it is a start. I am not involved in this project, but I would like to congratulate everyone who has dedicated some of their time to such a noble goal.

When it comes to articles and tutorials, it is great to see not only an option, but sometimes diversity. In some countries, for instance, there is already more than one magazine about the Java platform, as is the case for Brazil. Great open-source projects, once (and still, sometimes) accused of not having formal documentation, now have translation teams working on their docs. Translated Books become available faster, although quality can be low at times. However, as competent developers who are good at English are now being hired as revisors, the final result tends to improve.

Online book translations definitely take longer, but usually lead to better results. I've founded a translation effort for Bruce Eckel's famous book, Thinking in Java, several years ago (with his permission, of course), and although I am not able to contribute to it anymore, many volunteers keep working on the project, Pensando em Java.

So, what is the point of this post? Actually, there are a few:

• If you are foreigner, change your attitude! Many folks have criticised translation efforts (especially the Javadoc one) because they think it will lead to dumber programmers. The fact is bad programmers will always exist, but good ones now take a lot longer to explore their potential due to the language barrier. As a good developer who wants to work on a great team, you should encourage these initiatives, not the opposite.
• If you have the time, skills and desire, join the translation efforts. You will certainly learn a lot, get to know talented folks and help those who speak your language.
• Recognize the value of original content written in your language, such as magazines and blogs. And, if you can, create original material as well.
• Finally, if you are a developer/commiter/project owner, don't be hard on those asking questions in your lists/forums in a foreign language or even in bad English (worse than mine :-P). Rather try to find users capable of answering their questions on their native language or make specific questions that help you understand what the person wants to know.

When you support those working on making Java easy to learn, no matter what language they speak, you are just strengthening the community. And a strong community will certainly last longer, as well as your current job :-)

PS: for those who speak Portuguese, I've created a new blog at http://blog.michaelnascimento.com.br/.

Para aqueles que falam português, eu criei um novo blog em http://blog.michaelnascimento.com.br/.

This work is licensed under a Creative Commons License.