9

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).
Community
  • 1
  • 1
M Sach
  • 33,416
  • 76
  • 221
  • 314

3 Answers3

7

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.
Tom Anderson
  • 46,189
  • 17
  • 92
  • 133
  • Thanks Tom for beautiful clarification. two more clarification as you told corba classes are not defined by java standar but they i can see these classes under jre6/jdk.1.6 lik class org.omg.CORBA.AnyHolder. Another question i want to ask why javax.servlet, is not included in core java kib when it is extensively used. Is it because they are specific servlet container like tomcat and different meainig for them?Thats why i can see these libraries inder container/lib folder but not as part of jre6/jdk1.6? – M Sach Feb 29 '12 at 17:24
  • The CORBA classes are included in the JDK, just as much as fundamental things like java.lang.String, even though Sun didn't define them. They thought they were so useful that everyone should have them (or at least, they did back in 1998). The same goes for the org.w3c.dom and org.xml.sax classes. – Tom Anderson Feb 29 '12 at 18:22
  • 1
    The servlet classes are not included in the JDK because there's no way to use them without a servlet container (like Tomcat or Jetty). It would be impossible to use them in a desktop application or an applet, for example. So, they are not in the basic JDK. – Tom Anderson Feb 29 '12 at 18:27
  • There are some packages, like javax.inject, which could be useful anywhere, and so could be in the JDK. However, they are quite new, so they have been defined separately. It's possible that one day, they will move into the JDK. – Tom Anderson Feb 29 '12 at 18:28
3

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.

Taymon
  • 24,950
  • 9
  • 62
  • 84
1
  1. They often come from parties that are not Sun/Oracle. E.G. 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.

Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
  • One more question dou have any idea why java.lang does not need to be imported while other need to be in jre6. Is it because lang classes are used more frequently? – M Sach Feb 29 '12 at 17:26