CODEWITHSUNDEEP
javajakarta-ee
asdaf rwgafe
asdaf rwgafe

Reputation: 41

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

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?

Upvotes: 1

Views: 661

Answers (2)

Stephen C
Stephen C

Reputation: 718886

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

Upvotes: 3

mentallurg
mentallurg

Reputation: 5207

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.

Upvotes: 0

Related Questions