tags:

views:

2345

answers:

4

Hi!

What's the rationale behind the javax package? What goes into java and what into javax?

I know a lot of enterprise-y packages are in javax, but so is Swing, the new date and time api (JSR-310) and other J2SE packages.

+7  A: 

I think it's a historical thing - if a package is introduced as an addition to an existing JRE, it comes in as javax. If it's first introduced as part of a JRE (like NIO was, I believe) then it comes in as java. Not sure why the new date and time API will end up as javax following this logic though... unless it will also be available separately as a library to work with earlier versions (which would be useful).

I believe there are restrictions on the java package - I think classloaders are set up to only allow classes within java.* to be loaded from rt.jar or something similar. (There's certainly a check in ClassLoader.preDefineClass.)

Jon Skeet
+5  A: 

java packages are "base", and javax packages are extensions.

Swing was an extension because AWT was the original UI API. Swing came afterwards, in version 1.1.

duffymo
Swing was not part of 1.1. There was a version of Swing that ran on 1.1 as a library.
Tom Hawtin - tackline
There's the key - "library", not part of the JDK. Do I have the version wrong? My javadocs suggest that JButton has been since 1.3, so perhaps my memory failed me.
duffymo
+3  A: 

The javax namespace is usually (that's a loaded word) used for standard extensions, currently known as optional packages. The standard extensions are a subset of the non-core APIs; the other segment of the non-core APIs obviously called the non-standard extensions, occupying the namespaces like com.sun.* or com.ibm.. The core APIs take up the java. namespace.

Not everything in the Java API world starts off in core, which is why extensions are usually born out of JSR requests. They are eventually promoted to core based on 'wise counsel'.

The interest in this nomenclature, came out of a faux pas on Sun's part - extensions could have been promoted to core, i.e. moved from javax.* to java.* breaking the backward compatibility promise. Programmers cried hoarse, and better sense prevailed. This is why, the Swing API although part of the core, continues to remain in the javax.* namespace. And that is also how packages get promoted from extensions to core - they are simply made available for download as part of the JDK and JRE.

Vineet Reynolds
+2  A: 

originally javax was intended to be for extensions, and sometimes things would be promoted out of javax into java.

One issue was Netscape (and probablu IE) limiting classes that could be in the java package.

When Swing was set to "graduate" to java from javax there was sort of a mini-blow up because people realized that they would have to then modify all of their imports. Given that backwards compatibility is one of the primary goals of Java they changed their mind.

At that point in time, at least for the community (maybe not for Sun) the whole point of javax was lost. So now we have some things in javax that probably should be in java... but aside from the people that chose the package names I don't know if anyone can figure out what the rationale is on a case-by-case basis.

TofuBeer