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 IE 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.

Answer 3

1. They often come from parties that are not Sun/Oracle. EG The org.omg package was created (apparently) by folks at http://omg.org/ Do you see the connection between package name and domain name?
2. No, if they are listed in the J2SE JavaDocs for a particular version, they come standard with that version. Here are the packages available to (included by default) J2SE versions 6 & 7 .
3. Yes, they are on the class-path automatically. Try importing one of the classes and compiling/running it to confirm that. OTOH note that they are like the AWT classes ( Color , Font etc.), where they can be imported, as opposed to java.lang package, whose classes do not need to have an import statement in the code.

---

java.lang does not need to be imported ..Is it because lang classes are used more frequently?

Basically, yes. Note that it is only of relevance to the compiler. Class files contain the fully qualified class-name, AFAIU.