This question already has answers here:
Difference between Java SE/EE/ME?
(14 answers)
Closed 7 years ago.
What's the main difference between Java SE and Java EE?
Java SE (formerly J2SE) is the basic Java environment. In Java SE, you make all the "standards" programs with Java, using the API described here. You only need a JVM to use Java SE.
Java EE (formerly J2EE) is the enterprise edition of Java. With it, you make websites, Java Beans, and more powerful server applications. Besides the JVM, you need an application server Java EE-compatible, like Glassfish, JBoss, and others.
Java SE stands for Java standard edition and is normally for developing desktop applications, forms the core/base API.
Java EE stands for Java enterprise edition for applications which run on servers, for example web sites.
Java ME stands for Java micro edition for applications which run on resource constrained devices (small scale devices) like cell phones, for example games.
http://www.dreamincode.net/forums/topic/99678-j2se-vs-j2ee-what-are-main-differences/
As far as the language goes it is not as though java changes. Java EE has access to all of the SE libraries. However EE adds a set of libraries for dealing with enterprise applications.
Java EE is more like a "platform" or an general area of development.
In Java SE you write applications that run as standalone java programs or as Applets. In JavaEE you can still do this, but you can also write applications that run inside of a Java EE container. The container can do a great amount of management for you such as scaling an application across threads, providing resource pools, and management features.
Java EE has a web framework based upon Servlets. It has JSP (Java Server Pages) which is a templating language that compiles from JSP to a Java servlet where it can be run by the container.
So Java EE is more or less Java SE + Enterprise platform technologies.
Java EE is far more than just a couple of extra libraries (that is what I thought when I first looked at it) since there are a ton of frameworks and technologies built upon the Java EE specifications.
But it all boils down to just plain old java.
Java SE refers to the standard version of Java and its libraries. Java EE refers to the Enterprise edition of Java which is used to deploy web applications.
Java EE is enterprise edition.
Includes jsp, servlets, beans, and some other stuff for server programming.
Java SE is standard edition. This is plain old Java. Includes GUI stuff.
First, J2SE and J2EE have been renamed. They're now Java SE and Java EE.
Essentially, Java SE is your standard Java designed for end-users. That's what you'd develop to for desktop applications. Java EE is the enterprise edition, designed for server programming, such as SOA and web applications.
Best description i've encounter so far is available on Oracle website.
Java SE's API provides the core functionality of the Java programming language. It defines everything from the basic types and objects of the Java programming language to high-level classes that are used for networking, security, database access, graphical user interface (GUI) development, and XML parsing.
The Java EE platform is built on top of the Java SE platform. The Java EE platform provides an API and runtime environment for developing and running large-scale, multi-tiered, scalable, reliable, and secure network applications.
If you consider developing application using for example Spring Framework you will use both API's and would have to learn key concept of JavaServer Pages and related technologies like for ex.: JSP, JPA, JDBC, Dependency Injection etc.
Java SE contains all the base packages. Some of the base packages are written in Java and some are written in C/C++. The base packages are the fastest because there are no additional layers on top of their core functionality.
Java EE is a set of specifications and the respective implementations are all built using Java SE base packages which happen to already contain everything required for any application. For example, for a web application, here is a Java SE Web Server and a Java SE Database.
Java SE 9/10 is expected to contain better support for native in order to improve the inherent performance issues it has from being an interpreted language. Using the enormous Java EE implementations implies a willingness to sacrifice performance, scalability and a lot of time and money for education and updates, in exchange for project standardization.
JavaSE and JavaEE both are computing platform which allows the developed software to run.
There are three main computing platform released by Sun Microsystems, which was eventually taken over by the Oracle Corporation. The computing platforms are all based on the Java programming language. These computing platforms are:
Java SE, i.e. Java Standard Edition. It is normally used for
developing desktop applications. It forms the core/base API.
Java EE, i.e. Java Enterprise Edition. This was originally known as
Java 2 Platform, Enterprise Edition or J2EE. The name was eventually
changed to Java Platform, Enterprise Edition or Java EE in version 5.
Java EE is mainly used for applications which run on servers, such as
web sites.
Java ME, i.e. Java Micro Edition. It is mainly used for applications
which run on resource constrained devices (small scale devices) like
cell phones, most commonly games.
In Java SE you need software to run the program like if you have developed a desktop application and if you want to share the application with other machines all the machines have to install the software for running the application. But in Java EE there is no software needed to install in all the machines. Java EE has the forward capabilities. This is only one simple example. There are lots of differences.
The biggest difference are the enterprise services (hence the ee) such as an application server supporting EJBs etc.
Related
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?
... 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.
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.
I am currently designing a SDK that is intended to be used in both desktop and web applications. Currently I have been developing this SDK in using the JavaSE-1.6 Library and utilizing the Apache HttpComponents library as well as the JibX Library for web connections and xml parsing respectively.
If I wish to develop a web application using the JavaEE library, would I be able to use the SDK that I have developed in JSE-1.6?
If so, are there any compatibility issues that I need to be aware of?
If not, would it be better to develop the SDK in JavaEE, or would I run into the same compatibility problems if I wished to create a desktop application?
J2EE/Java EE is not mutually exclusive from Java SE as you seemed to expect, given the question. Instead, Java EE requires Java SE to run. So if you just design your API to be compatible with Java SE, then it'll work equally fine on Java EE.
As to the version compatibility, checkout Wikipedia on the subject. For example, the current Java EE 6 requires a minimum of Java SE 1.6.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Java EE has this "mysterious shroud" around it for younger Java developers - one that I've been trying to lift myself for quite a while with little success.
Confusion arises from:
Java EE seems to be both a library and a platform - there are multiple ways to "get" the Java EE library, typically from something like Oracle's Java EE SDK download. However, the Java EE library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc). Why? Can't the libraries function outside of the application server environment? Why do I need something massive as JBoss just to compile simple code to send an email?
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
What can one do with Java EE that they cannot do with standard Java?
What can one do with standard Java that they cannot do with Java EE?
When does a developer decide they "need" Java EE?
When does a developer decide they do not need Java EE?
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)?
Thanks for helping me clear the flog!
Why can't the libraries function outside of the application server environment?
Actually they can. Most of the libraries can be directly used standalone (in Java SE) or included in a .war (practically that's nearly always Tomcat). Some parts of Java EE, like JPA, have explicit sections in their respective specifications that tells how they should work and be used in Java SE.
If anything, it's not so much an application server environment per se that's at stake here, but the presence of all other libraries and the integration code that unites them.
Because of that, annotations will be scanned only once for all your classes instead of every library (EJB, JPA, etc) doing this scanning over and over itself. Also because of that, CDI annotations can be applied to EJB beans and JPA entity managers can be injected into them.
Why do I need something massive as JBoss just to compile simple code to send an email?
There are a few things wrong with this question:
For compiling you only need the API jar, which is below 1MB for the Web Profile, and a little over 1MB for the full profile.
For running you obviously need an implementation, but "massive" is overstating things. The OpenJDK for example is around 75MB and TomEE (a Web Profile implementation containing mail support) is only 25MB. Even GlassFish (a Full Profile implementation) is only 53MB.
Mail works perfectly fine from Java SE (and thus Tomcat) as well using the standalone mail.jar and activation.jar.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Java EE in a way was one of the first attempts to split up the already massive JDK into chunks that are easier to manage and download. People are already complaining that the graphical classes (AWT, Swing) and Applets are inside the JRE when all they do is run some commands on a headless server. And then you also want to include all the Java EE libraries in the standard JDK?
With the eventual release of modularity support we'll just have a small base JRE with many things separately installable as packages. Perhaps one day many or even all classes that now make up Java EE will be such package as well. Time will tell.
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
There are more than just two flavors of Java SE. There is at least the IBM JDK, the previous BEA one (JRocket, which is being merged into the Oracle/Sun one because of the acquisition), various other open source implementations and a slew of implementations for embedded use.
The reason behind Java SE and EE being a specification is that many vendors and organizations can implement it and thus it encourages competition and mitigates the risk of vendor lock-in.
It's really no different with C and C++ compilers, where you have many competing offerings as well all adhering to the C++ standard.
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)
Java EE builds on Java SE, so it trails behind. The versions do correspond though. Java EE 5 requires Java SE 5. Java EE 6 requires Java SE 6 and so on. It's just that mostly when Java SE X is current, Java EE X-1 is current.
Here are a few quickly composed answers to your questions...
Why can't JavaEE libraries function without an application server?
The services provided by JavaEE (container managed transactions, container managed dependency injection, timer service, etc..) inherently involve JavaEE compliant Application Servers (for example: GlassFish, JBoss, WebSphere, etc...). Therefore the JavaEE libraries serve no purpose without such a container. "Why do I need something as massive as JBoss just to compile simple code to send an email?" You don't. There are ways to send an email without JavaEE... But if you want to do it the JavaEE way, you need a JavaEE container.
Why are JavaEE libraries not included with JavaSE download?
The same reason that many libraries aren't included: it would be overkill. Since you can't even use the JavaEE libraries without an application server, why bother to include them? JavaEE should be downloaded if and when a developer installs an application server and decides to use JavaEE.
Why are there so many JavaEE offerings?
Are there really "so many" JavaEE offerings? If so, please list some of them. More accurately I believe there are multiple implementations of the same APIs.
What can one do with JavaEE that they can't do without standard Java?
Lots. You can't rely on an application server to manage transactions or persistence contexts without JavaEE. You can't allow an application server to manage EJB dependency injection without JavaEE. You can't use an application managed timer service without JavaEE. The answer to this question should make the answer to the first question quite clear... Most of the services provided by JavaEE require a JavaEE container.
What can you do with JavaSE that you can't do with JavaEE?
Um... I don't know.
When does a developer decide they need JavaEE?
This question is completely subjective... But if you need any of the services provided by JavaEE, you start to think about it. If you don't know what JavaEE is... you probably don't need it.
When does a developer decide they do not need JavaEE?
See previous answer.
Why is JavaEE library version not in sync with JavaSE version?
Good question. I won't pretend to know how to answer it... But I would guess the answer is: "because they're not in sync".
At bird's eye view, Java EE is a platform, i.e. something that we can build on.
Taking a more technical perspective, the Java Enterprise Edition standard defines a set of APIs commonly used for building enterprise applications. These APIs are implemented by application servers - and yes, different application servers are at liberty to use different implementations of the Java EE APIs.
However, the java ee library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc).
You compile against the Java EE APIs, so you only need those APIs at compile time. At runtime, you'll also need an implementation of these APIs, i.e. an application server.
Why do I need something massive as JBoss just to compile simple code to send an email?
You don't. However, if you wish to use the Java EE API for sending mail, you will need an implementation of that API at runtime. This can be provided by an application server, or by provided by a stand alone library you add to your classpath.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Because only the APIs are standardized, not the implementations.
Why are there so many Java EE offerings
Because people disagree on the right way to implement certain features. Because different vendors compete for market share.
What can one do with Java EE that they cannot do with standard Java?
Since Java EE implementations are built with "standard Java": Nothing. However, leveraging the existing libraries can save a great deal of effort if you are solving typical enterprise problems, and using a standardized API can prevent vendor lock-in.
What can one do with standard Java that they cannot do with Java EE?
Nothing, since Java EE includes Java SE.
When does a developer decide they "need" Java EE? When does a developer decide they do not need Java EE?
Generally speaking, the Java EE APIs solve typical, recurring problems in enterprise computing. If you have such problems, it usually makes sense to use the standard solutions - but if you have different problems, different solutions may be called for. For instance, if you need to talk to a relational database, you should consider using JPA. But if you don't need a relational database, JPA won't help you.
What is Java EE?
Let's start from canonicity definition at wiki:
Java Platform, Enterprise Edition or Java EE is Oracle's enterprise
Java computing platform. The platform provides an API and runtime
environment for developing and running enterprise software, including
network and web services, and other large-scale, multi-tiered,
scalable, reliable, and secure network applications.
The main point here is that Java EE is a platform provides an API, not some concrete library.
What for Java EE needed?
The main scope of Java EE is the network based applications, unlike Java SE oriented to the desktop applications development with simple network support. This is the main diference between them.
Scalability, messaging, transactioning, DB support for every application... the need in all of this has increased with the evolution of the network.
Of course a lot of ready solutions which Java SE provides are useful for network development, so Java EE extends Java SE.
Why do we need application servers to run our code?
Why do we need operation systems? Because there are a lot of painful work with hardware we need to do to make even simpliest application. And without OS you need to do it again and again. Oversimplified OS is just a programmatic container, which provides us a global context to run our applications.
And this is what the application servers are. They are allows us to run our applications in their context and provides us a lot of highlevel functionality which is needed for enterprise highloaded network applications. And we are don't want to write our own bicycles to solve this problems, we are want to write code which will satisfy our business needs.
Another example here could be JVM for Java.
Why Java EE doesn't contains onboard app server?
Hard to say for me. I think, it was done for more flexibility. Java EE says what they should do, they decide how to do it.
Why JVM doesn't include Java EE?
Because they directed to different market sectors. Java EE has a bunch of functionality which is doesn't need for usual desktops.
Why are there so many Java EE offerings?
Because Java EE only describes the behaviour. Everybody can implement it.
What can one do with Java EE that they cannot do with Java SE?
To conquer the internet. It's really hard to do with Java SE applets and sockets :)
What can one do with Java SE that they cannot do with Java EE?
As mentioned above Java EE extends Java SE, so with Java EE you should be able to do everything what is available for Java SE.
When does a developer decide they "need" Java EE?
When they need the power of Java EE. All what is mentioned above.
When does a developer decide they do not need Java EE?
When they write a usual console or desktop application.
Why versions of Java SE and Java EE are unsynced?
Java always had troubles with it's technologies naming and versioning. So this situation is not an exception.
Java EE is all about container concept. Container is an execution context within which will run your application and which provide this last a set of services. Each kind of service is defined by a specification named JSR. For example JSR 907, JTA (java transaction Api) which provide a standard way to manage distributed transaction against different resources. There are generally many different implementations for a given JSR, the implementation you will use depends on the container provider, but you don't really mind about that as you are sure the behavior respect the predefined contract : the JSR API. So to take advantage of Java EE, you need to run your application inside a container. The two main ones are EJB and servlet container which are both present on any Java EE certified application server.
The aim of all of this is to defined a standard execution environment to allow to package your application with only the essentials, id.est. your business. It avoids to depend on a unknown and various set of third-party libraries that you would have to package and provide with your app otherwise, and which may be sources of conflict with other apps on the server. In Java EE you know that all standard non functional requirements like security, transaction, scalability, remote invocation, and many more will be provided by the container (factorized for all apps running inside it) and you just have to base your work on its.
I know this is a stupid question. But I really have very limited knowledge in programming. I've experience writing PHP code back in school, and I know that there is a framework called codeigniter, which includes very basic functions and libraries used for facilitating PHP programming.
Is Java EE to Java and WebLogic like codeigniter to PHP and some php-based web application (e.g., a forum)? I mean, is Java EE a framework or something like that?
Java EE is not a framework. It is a seperate edition of java for Web development process. for deploy(run) web application we need a server. Weblogic is one of the server.
Java EE is a standard. According to this
Java Platform, Enterprise Edition (Java EE) 6 is the industry standard for enterprise Java computing. Utilize the new, lightweight Java EE 6 Web Profile to create next-generation web applications, and the full power of the Java EE 6 platform for enterprise applications. Developers will benefit from productivity improvements with more annotations, more POJOs, simplified packaging, and less XML configuration.
WebSphere Application Server, JBoss Application Server and other are implementations of the above mentioned standards.
Google really helps a lot, please look into it before posting :)
I can code in Java, and I'm trying to understand the wiki article on frameworks and how they relate to java. I think java = the platform and the frameworks are things like Java EE, jsp, etc. (I've never used any of those)
I'm trying to see the connection here.... Also, does each framework get its own compiler? Do they all use the JVM?
From my understanding: Java is a programming language (that compiles through the JVM), it is "open source" and can be extended with different APIs. Java EE (Enterprise Edition) is an API of Java SE (Standard Edition), it adds more functionality to the Standard API of Java.
Frameworks are supposed to make programming in languages like Java easier, and decrease development time. For example a framework named "Play" is a pretty popular java framework that helps develop web pages. Frameworks are not seperate from the language, they use the language itself so they don't get their own compiler all it's doing is using the language.
Someone (or a company) just creates their own methods in java and make them available to use for anyone that wants to use it. Anyone can create a framework, you can probably think of a framework as a Lego set where each Lego piece is a method available to build your own program (or website, depending on what the framework was created for), eventually you can build your own program using those methods from the framework. (hope this is making sense, heh)
Strictly speaking Java is a programming language. Just a programming language. It needs an implementation if you are to compile and run programs.
The Java implementation(s) consist of bytecode compilers and related tools, and a runtime platform. The runtime platform consists of an implementation of the Java Virtual Machine (JVM), together with the runtime libraries that contain the standard classes.
There are in three primary Sun/Oracle Java "platform" types ... or Editions as they are called:
Java Standard Edition (SE) is the normal general purpose platform. Unless specified otherwise, this is what most people will be using.
Java Micro Edition (ME) is designed for embedded devices such as smart phones, set-top boxes and the like. It is a very cut-down version of Java, with some significant differences in some area.
Java Enterprise Edition (EE) is an extended platform designed to support enterprise computing. It adds support for web server development, component-based systems (EJB) and other things. (In fact J2EE is a bit more woolly than this, because there are web container distributions out there like Tomcat, Jetty and so on that provide a subset of the Java EE technologies ... on top of a standard Java SE platform.)
A framework is a different idea. Frameworks are typically systems of libraries that support a particular way of designing and implementing software applications. So for instance:
The core Spring Framework supports a style of programming where the system is "wired up" from a bunch of components at start up.
Spring MVC (and other frameworks) support web servers that are implement according to the Model-View-Controller design pattern.
A RESTful web server framework supports web servers that follow the RESTful model.
And so on.
These frameworks typically run on one or more kind of Java platform, depending on what they are doing.
Also, you could make a case that some of the technologies that are in Java EE platform are actually framework technologies. Servlets and EJBs are prime examples.
If you are familiar with jQuery in javascript, well jQuery is a javascript framework. Same goes for framework for java. It just makes programming easier