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.
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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 asjava. Not sure why the new date and time API will end up asjavaxfollowing 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 injavaafter all.I believe there are restrictions on the
javapackage – I think classloaders are set up to only allow classes withinjava.*to be loaded fromrt.jaror something similar. (There’s certainly a check inClassLoader.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.beansreally that "core" to Java, for example?