1

I'm trying to understand the differences between Java SE and EE. There is a lot of information out there but from my current limited understanding, it seems like Java EE is just Java SE with some stuff added on top of it. Why can't I just use Java SE and import API or packages when I need them? For example if I need to be able to connect to a database I can import the JDBC API, is doing that any different that using JDBC in Java EE?

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
asdaf rwgafe
  • 41
  • 4

2 Answers2

3

... it seems like JAVA EE is just JAVA SE with some stuff added on top of it.

That is incorrect.

In reality, Java EE is a specification, and a set of libraries that provide API interfaces to program against. What Java EE per se does NOT provide is the implementations of those interfaces.

A Java EE implementation is embodied in code that has been written by Java EE vendor. That implementation may or may not be a product that you have to pay for.

The other thing is that Java SE is not a part of Java EE. Not in any sense. Java EE APIs (and implementations) depend on a JVM and a Java SE class library, but they are separate things, and they are typically distributed separately.

Why can't I just use JAVA SE and import API or packages when I need them?

Assuming that you have downloaded the Java EE API JAR files (or your build tool has done it for you), you can compile your code against the Java EE APIs.

But you can't >>run<< your code on a plain Java SE platform because neither Java SE or the Java EE API JARs contain the classes that implements the Java EE APIs; i.e. the servlet framework, etcetera.

If you try a Java EE app without the vendor-provided code, it won't work. (If you don't believe me / us, try it for yourself.)

For example if I need to be able to connect to a database I can import the JDBC api, is doing that any different that using JDBC in JAVA EE?

JDBC used to be a Java EE API, but now it is a Java SE API. (Check the Java SE API documentation!)

But here's the thing. If you want to connect to a database using JDBC, your application needs to use database specific JDBC drivers ... which you get from the database vendor. (Just like you get a Java EE implementation from a Java EE vendor!)

Why can't I just import libraries into Java SE instead of paying for Java EE?

Most of this has been addressed above. But you also mentioned "pay for".

The reason you need to pay is because Java EE implementations are typically proprietary products. A company invested a lot of money in developing their codebase, and they want to make a return on that investment.

And indeed, from Java 9 onwards, Oracle Java SE is not free either ... for most use-cases.

In either case, there are three alternatives if you really don't want to pay:

  • Find a free (e.g. open source) implementation. They exist for Java SE and Java EE.
  • Develop your own implementation of the relevant specs. (That will be more expensive in terms of time than paying a vendor.)
  • Use the product without paying the required license fee, and hope that you don't get sued for a lot of money copyright violation, etcetera.

Isn't Java platform independent?

The Java programming language is platform independent.

The Java SE APIs are platform independent (more or less).

A Java SE implementation is NOT platform independent. If you download Java SE for Windows and try to run it on Linux, it won't work. (Never has, never will).

The "write once, run everywhere" mantra assumes that you have installed a Java SE implementation of the appropriate version on the platform. It doesn't imply that such an implementation exists, or that it will be available for free, or that it will be installed everywhere.

What "write once, run everywhere" mantra is actually saying is that you don't have to modify your Java application in order to make it run on another Java platform. (And note that there a number of caveats on the nature of the application for WORE. For example, it mustn't depend on native libraries or external applications that may or may not be present.)

Can't I import the Java EE library, get java.servlet.Servlet, program with it, the host my application server on any computer that has a connection to the internet and a static Ip address?

In two words: You can't.

No matter how many times or how many different ways you ask.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • @chrylis -cautiouslyoptimistic- i think i get it now, Thank you so much for answering. So if im getting it right you can code using Java EE API's, but to run it you need a Java EE application server like Glassfish or Tomcat, or use spring which has its own server right? I got the idea of paying because I read that in order to use Java EE for enterprise purposes you need to subscribe to Oracles Java enterprise subscription? – asdaf rwgafe Nov 28 '20 at 08:14
  • I think you need to re-check that. I think what you are actually referring to is a Java SE subscription. – Stephen C Nov 28 '20 at 08:47
  • JDBC has been a part Java SE from its start (it is in the `java.sql` package, and was sometimes referred to a JDBC Core). JDBC was introduced in Java SE 1.1 (1997) and predates Java EE by about 2 years (in 1999). Initially the JDBC 2.0 Extension API (the `javax.sql` package) was more geared towards J2EE, but it was never only part of J2EE that I'm aware of. The JDBC 2 Standard Extension API was later integrated in Java SE in Java 1.4 (IIRC). It is true there are elements of the JDBC specification that are only 'required' for Java EE compliance (see section 6.4 of the JDBC specification). – Mark Rotteveel Nov 28 '20 at 09:42
0

The Java EE libraries you mean only define interfaces. you don't need to pay for them. But you need an implementation of this interfaces. For instance, you can import Java EE library and you will get java.servlet.Servlet. But will have no implementation of this class.

To run a Java EE application you need a platform that, simple said, implements all these interfaces. Such platforms are so called so called Java EE runtimes or application servers like WildFly or WebSphere.

mentallurg
  • 4,967
  • 5
  • 28
  • 36
  • Isn't Java platform independent? Cant I import the Java EE library, get java.servlet.Servlet, program with it, the host my application server on any computer that has a connection to the internet and a static Ip address? – asdaf rwgafe Nov 28 '20 at 07:14
  • @asdafrwgafe "my application server", that is exactly what you need to **run** Java EE: an application server... you can either get a free Java EE application server, or a paid one (or a free one with a support contract). That said, some parts of Java EE are also available as standalone libraries (for example, JakartaMail (formerly JavaMail)). – Mark Rotteveel Nov 28 '20 at 09:48
  • @asdafrwgafe: You can import `java.servlet.Servlet`, but you have no code that implements it. You need a code that receives HTTP requests, parses them, creates Java objects from them, represents it as a Servlet, Request, Headers, then converts your Response object into a correct HTTP response, sends it to the client / browser. Despite HTTP is well defined, it pretty complex: you have to correctly handle multiple status codes, multiple headers, to correctly work with multipart requests, with HTTP chunks etc. And Servlets are only a part of Java EE. Java EE is much more. – mentallurg Nov 28 '20 at 12:01