The story of a URL

It could have been an utterly uninteresting change, something you’d wave away, but it wasn’t. Small details can hide important differences. When Oracle took over Sun, we heard a lot about how seriously Oracle takes Java. Since I got an always-on internet connection and Google became capable of granting my most secret wishes, I’ve stopped keeping the Javadoc for the standard Java API on disk. If I need to look something up in the API, I always go through Google. I type the class name and, bang, there’s the result.

Given the way Google indexes and searches, sometimes you get an older version of the Javadoc. Say you get http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html, and want version 1.6. What do you do? Change the five to a six, and there’s the result you expected.

Sorry, don’t be misled. That was how it worked before Sun became part of Oracle. Then came the move to Oracle’s IT infrastructure. In place of those human-readable URLs, you now get a monstrosity like http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/api/java/lang/Object.html. On top of the URL being awful, changing the number doesn’t get you another version. I’d really like to know what or who E17476_01 is and what the magic cd in the URL means. To top it off, Oracle’s servers are terribly slow. It looks more like there might only be one server.

I complained about it on Twitter sometime last week. Today I saw that others had noticed it too. Somebody must already have given Oracle an earful, because: @oracletechnet: Yes, have noted javadoc URL issues and we are exploring solutions with IT right now. Please stand by..

This isn’t the only thing (see Clouds, sunshine, or a cozy little world for Java ) that makes me feel Java has taken a back seat at Oracle. I don’t buy the arguments about moving to new infrastructure. If I take Java seriously, how can I make such a mess of something as simple as access to its documentation? The answer is that I probably don’t take it all that seriously.