--- Leon Rosenberg <[EMAIL PROTECTED]> wrote: > On 1/30/06, Tim Lucia <[EMAIL PROTECTED]> wrote: > > Hibernate is not J2EE "based". It just so happens > it provides a EJB-free > > solution to a servlet container environment. > Hibernate does not require > > J2EE. > > I think hibernate supports JTA and JDBC? Ok, JDBC > isn't J2EE since 3.0 > but was before. (Actually it should become J2EE in > 4.0, but this was > changed). > But JTA is J2EE as well as JMX, isn't it? > > > Tim > Leon. > > But actually it doesn't play a role..., just another > crutch to keep > relational databases in business :-) > > Actually JDBC isn't J2EE at all. XA transaction stuff is J2EE. XA can apply to a database or other transaction types as well completely unrelated to a database. JDBC is a standard J2SE API. See: http://java.sun.com/j2se/1.5.0/docs/api/
JDBC has been in the standard edition since 1.0 or 1.1. Everything in the docs here are standard java as of 1.5. See the 1.4.2 docs for pre 5.0 and obviously other versions to get pre version information for the version you look at. Thus, everything in this set of documentation is standard or J2SE and is not J2EE. For the list of APIs which is only J2EE (thoughmany if not most or all are available as separate API libraries from either Sun, Apache, or some other offering) see (this is 1.4): http://java.sun.com/j2ee/1.4/docs/api/index.html For a list of J2EE standards/specifications and future ones see: http://www.jcp.org and sort by technologies. and see: http://java.sun.com/j2ee/1.4/docs/index.html#specs Just want everyone to be clear what APIs are really J2EE and which ones are not before we discuss it. It seems to much misinformation gets out accidentally. The best source is to read the JSRs at the JCP. Then see a company such as Sun which lists all of the specifications for an easier view of the list. Doing that you can also see some applications and implementations which use the specifications. You can certainly create more than a trivial application completely skipping J2EE altogether....it just helps with some types of applications. For instance, you can take an implementation of a certain specification such as web applications and servlets. Create a servlet based web application and merely touch an API and specification not the complete J2EE stack and really don't have to call it J2EE if you don't want. Refer to it as it's JSR or say "Servlet Spec 2.2, 2.3, or 2.4...pick one). Take Tomcat web applications for instance. You can reuse the Tomcat APIs to create a web application linking to the servlet.jar available from a distribution without ever downloading J2EE and linking to it. I believe what we see more of is the marketing hype and FUD confuses the use cases for many people and recruiters and human resource departments at organizations make it even more confusing for some others by the fact they don't know what their organization needs and all they know is what is on paper and then they try to talk about things like they know what they are talking about. That doesn't change the fact that one can create their own version of an API to match a certain specification then use that for linking and building to deploy to another system which supports many APIs and specifications including the one you may have targeted. So, just to be clear. Not all the APIs and specifications of J2EE have to be used to have a compliant application nor does a developer have to install J2EE to create a J2EE compliant application, they merely have to link to a set of interfaces matching a subset of J2EE for any given requirement, and sometimes this means it's easier to just download J2EE and get it all. I love software and programming :-D, Wade --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
