Some basic questions about javax vs java packages

Question

When I go to JavaDocs I find some classes in java package while some are in javax. Then I came across javax vs java package.

What i get from this link almost from all answers is that javax package is just an extension of java library. I mean first Java must had come with core Java libraries I.E. java package but when some more package got developed they released with javax. Right?

Some question which immediately comes to my mind as developer. What are implications these of differently named packages for a Java developer. Here are the questions and analysis:-

1. Even if I agree javax is just extension of core java. But then again I see totally different packages like org.omg.CORBA etc. Why this is named javax.omg.CORBA?
2. Do these packages like javax, org, come with standard JDK and JRE download? Do these need to be downloaded separately from JSE 1.6?
3. Does the bootstrap classloader try to find the classes in these packages by default as it does in case of core Java classes (like java.lang).

Answer 1

I think it's fairly arbitrary. As Jon Skeet says in his answer to the question you link to, much of it historical. A good example of this is javax.sql - it contains classes to do with JDBC that were originally part of J2EE, but which were brought into J2SE in 1.4. So now there is a pointless split of classes between java.sql and javax.sql. There's no particular meaning attached to the java/javax split inside the JDK.

1. The CORBA classes are where they are because they aren't defined by the Java standard; they're translations of interfaces defined in the CORBA specifications.
2. There are plenty of javax.* packages that come with the standard J2SE JDK/JRE (javax.sql, javax.xml). There are also javax.* packages which don't (javax.inject, javax.servlet, etc). But there are no java.* packages which are not in the JDK.
3. I believe the bootstrap classloader loads java.* and javax.* classes alike.

Answer 2

Historically, the idea was that java.* packages would be the ones that shipped with the JDK, and the javax.* packages would be the ones that have to be downloaded separately. It still does work this way, to an extent; all java.* packages come with the JDK, and there are many javax.* packages, like for servlets, that have to be downloaded separately.

A monkey wrench was thrown into this scheme when Sun decided to move some javax.* packages, like Swing, into the main JDK. They were actually going to change the package name from javax.swing to java.swing, but when it became clear that this would break backwards compatibility for a huge amount of code, they decided instead to move the packages in, but keep the javax.swing name. So the name is no longer indicative, but is there for historical reasons.

It wouldn't surprise me if the same thing happened to the org.omg and org.w3c packages (they were third-party libraries that got moved into the core JDK and the names couldn't be changed). Regardless, if it's in the JDK API docs, you can use it without downloading anything apart from the main JDK, and the class loader will find it just fine.