472

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.

Solomon Ucko
  • 5,724
  • 3
  • 24
  • 45
Jaka Jančar
  • 11,386
  • 9
  • 53
  • 74
  • A optional package is an implementation of an open, standard API (examples of optional packages `JavaServlet`, `Java3D`). Most optional packages are rooted in the `javax.*` namespace, although there may be exceptions. – Lucky Nov 03 '16 at 07:36

8 Answers8

282

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

One issue was Netscape (and probably 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 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.

Hearen
  • 7,420
  • 4
  • 53
  • 63
TofuBeer
  • 60,850
  • 18
  • 118
  • 163
  • 15
    "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." People were complaining about something that could be accomplished with a regex that was a result of them using preproduciton quality code? – Sled May 10 '11 at 15:47
  • 11
    Yup. I wrote a tool in Visual Cafe to convert between the two (javax and java) before Sun decided to just keep it in the javax package. – TofuBeer May 10 '11 at 20:34
  • 6
    the swing problem could have been mitigated by having swing in both namespaces at the same time, adding deprecation warnings for the one in javax. – jgomo3 Oct 04 '20 at 01:06
  • 1
    @jgomo3 The problem with that is that, unless they were to add type aliases to Java, code using `java.swing` and code using `javax.swing` wouldn't be able to interoperate. – Solomon Ucko May 12 '23 at 02:56
  • 2
    @SolomonUcko you are right. Interesting language feature. Clojure has it. One workaround in Java would be to make `javax.swing.X` a dummy class extending `java.swing.X` for all `X`. – jgomo3 May 23 '23 at 14:11
  • @jgomo3 That would only solve one direction - an application using java.swing could not use a library using javax.swing - and it wouldn't be possible for final classes. – gbear605 Aug 09 '23 at 01:43
239

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). Note from many years later: it (date and time API) actually ended up being in java after all.

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

EDIT: While an official explanation (the search orbfish suggested didn't yield one in the first page or so) is no doubt about "core" vs "extension", I still suspect that in many cases the decision for any particular package has an historical reason behind it too. Is java.beans really that "core" to Java, for example?

Gaurav
  • 3
  • 4
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 7
    Because it's easier for aa reader to hit alt-t and type it than for me to cut and paste using iPad? ;). You're right, though, I *think* I meant http://download.oracle.com/javase/tutorial/ext/index.html. No offense BTW I usually find your answers useful I'm just surprised this one was accepted. – orbfish Nov 05 '11 at 21:40
  • 1
    The term "javax" doesn't appear anywhere in the link suggested earlier in this comment thread. – pamphlet Jan 28 '14 at 16:46
  • The new date and time API will actually ended up as `java.time` after all. – Michael Piefel Jul 25 '16 at 08:17
68

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.

Hearen
  • 7,420
  • 4
  • 53
  • 63
duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Swing was not part of 1.1. There was a version of Swing that ran on 1.1 as a library. – Tom Hawtin - tackline Apr 07 '09 at 23:12
  • 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 Apr 07 '09 at 23:22
  • 1
    So why is the new date and time API in javax.. date and time is not "base" ? – Pacerier Oct 18 '11 at 14:20
  • 1
    "... the new date and time api (JSR-310)..." - someone at Oracle/Sun decided that it was better put in javax, because it's a newer extension of the core libraries. If you disagree, best to take it up with them. – duffymo Oct 18 '11 at 14:50
  • Just for reference: they reverted that decision, and JSR-310 was put under `java.time`: http://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html – Mark Rotteveel May 04 '15 at 11:32
  • Just for reference: this answer is more than six years old. Doesn't change my point. – duffymo May 04 '15 at 11:34
40

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
  • 76,006
  • 17
  • 150
  • 174
4

java.* packages are the core Java language packages, meaning that programmers using the Java language had to use them in order to make any worthwhile use of the java language.

javax.* packages are optional packages, which provides a standard, scalable way to make custom APIs available to all applications running on the Java platform.

Lakshmi Prasanna
  • 347
  • 1
  • 2
  • 9
3

Javax used to be only for extensions. Yet later sun added it to the java libary forgetting to remove the x. Developers started making code with javax. Yet later on in time suns decided to change it to java. Developers didn't like the idea because they're code would be ruined... so javax was kept.

Miroslav
  • 41
  • 1
  • 6
2

Some packages like javax.swing were not included in java standard library at first. Sun company decided to consider them official and included them into the early versions of java as standard libraries or standard extensions.

By convention, all the standard extensions start with an X while they can get promoted to first-class over time like what happened for javax.swing.

Rezaeimh7
  • 1,467
  • 2
  • 23
  • 40
1

All the javax packages were aimed to be experimental packages. By the time Swing was stable enough and ready to be moved to the java package there was too much code out there that they decided to leave it as it is to keep their commitment with backwards compatibility. This is explained in the book Learn Java in 21 days from the Sams editorial, written by Laura Lemay and Rogers Candedhead.

Raydelto Hernandez
  • 2,200
  • 2
  • 16
  • 11