This question already has answers here:
Correlation between Java EE / J2EE to J2SE / JDK versions
(3 answers)
Closed 5 years ago.
I was under the impression that the release of Java SE 8 would come together with Java EE 8, yet I cannot find it anywhere.
It seems that it will be released later? https://en.wikipedia.org/wiki/Java_EE_version_history#Java_EE_8_.28JSRs_approved_on_22_Sep.2C_2014.2C_expected_Q3_2016_or_first_half_2017_Final_Release.29
So there is no connection between the 2? Java SE 8 still goes along with Java EE 7?
Java EE and Java SE are released separately and the versions do not match.
Java EE is a set of APIs (e.g. JMS for messaging, JPA for Object-Relational-Mapping to databases, JSF and JSP for webpages) which is implemented by different vendors of application servers (e.g. Oracle, IBM, Red Hat...) and extends Java SE. If you don't need any functionality from the Java EE APIs you are totally fine with just the plain Java SE.
Wikipedia defines Java EE as:
Java EE extends the Java Platform, Standard Edition (Java SE),
providing an API for object-relational mapping, distributed and
multi-tier architectures, and web services.
Wiki links:
Java platform:
https://en.wikipedia.org/wiki/Java_(software_platform)
Java SE:
https://en.wikipedia.org/wiki/Java_Platform,_Standard_Edition
Java EE:
https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
The Java EE platform is built on top of the Java SE platform, but they are not released together.
For instance, both Java EE 8 and Java SE 9 were released on 21st September 2017. But Java EE 8 requires Java SE 8 that released on 18th March 2014.
The Java SE platform
The Java SE platform 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 and XML parsing.
In addition to the core API, the Java SE platform consists of a virtual machine, development tools, deployment technologies, and other class libraries and toolkits commonly used in Java technology applications.
The Java EE platform
The Java EE platform is built on top of the Java SE platform and provides an API and runtime environment for developing and running large-scale, multi-tiered, scalable, reliable, and secure network applications.
Since September 2017 the Java EE 8 API artifacts are available on Maven:
Java EE 8 Platform
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>8.0</version>
<scope>provided</scope>
</dependency>
Java EE 8 Web Profile
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>8.0</version>
<scope>provided</scope>
</dependency>
Related
With every new release of Java EE, there's a bunch of new improvements and additions to the technology stack that come under it. JSF, JPA, EJBs will all have different versions associated with this new release. (Java EE 8 - JSF 2.3, JSP2.3, JPA 2.2, EJBs 3.2)
Java SE platform is releasing new version of Java SE every 6 months or so. How does this change fit in with the Java EE?
For example, if I'm developing an application in Java EE 8 which Java SE(9,10,11,12) should I use?
1. Can I use any version of Java SE with Java EE? (Java EE 8 + Java SE 11) or (Java EE 8 + Java SE 8) or (Java EE 8 + Java SE 10).
How does Java EE handles the ever changing Java SE? Because there's specific version specified for every technology used in Java EE 8 like JSF 2.3, JSP2.3, JPA 2.2, EJBs 3.2 .
2. Why isn't a specific version of Java SE used in Java EE to do the programming?
JDK 8+ is required, but...
It actually depends on your Java EE 8 vendor.
Java EE 8 (a.k.a. Jakarta EE) has a few API elements that require JDK 8, so the definitive baseline is at least JDK 8.
For instance, I use Wildfly 16 (= Java EE 8) with JDK 12 and it works flawlessly so far, though JDK 8 is required.
Other vendors like Glassfish, Weblogic might require different versions. Glassfish, for instance doesn't work yet on JDK 9+.
This question already has answers here:
Openjdk and Java webstart
(2 answers)
Closed 2 years ago.
I'm confused about the status of Java Web Start. On Oracle's Support Roadmap we can read this:
Support of Deployment Technology
The web deployment technology, consisting of the Java Plugin and Web Start technologies, has a shorter support lifecycle. For major releases through Java SE 8, Oracle provides five (5) years of Premier Support for these technologies. Extended Support is not available for the deployment stack, and will not be available for support beyond Java SE 9. See the Oracle Lifetime Support Policy for details.
Deployment Technology for Java SE 6 and Java SE 7 may be removed at any time after Jun 2017. Although the deployment stack may be included in Java SE 9 or later releases, Java SE 8 is the recommended and only supported version of the deployment stack.
Now, we have known for quite some time that applets and the Java Plugin were to be removed in a future version of Java, but I had never read about Java Web Start being a candidate for removal.
In Oracle's Java Platform, Standard Edition Deployment Guide#Getting Started (a Java 9 documentation page), Java Web Start is advertised as an alternative to the deprecated applet technology:
Although available and supported in JDK 9, the Applet API and the Java Plug-in are marked as deprecated in preparation for removal in a future release. Alternatives for applets and embedded JavaFX applications include Java Web Start and self-contained applications.
Am I worrying for nothing or I have missed an announcement about the deprecation of Java Web Start?
So far I only know about https://openwebstart.com/
The project was created exactly to fill the gap.
This question already has answers here:
Correlation between Java EE / J2EE to J2SE / JDK versions
(3 answers)
Closed 5 years ago.
I've been wondering if there is a correlation between versions of Java EE working on top of Java SE. I've found this question, but the answers there are outdated and not satisfying. My question is:
is there a tight coupling between EE and SE versions so that java EE 8 will only work with Java 1.8, java ee 7 will work only with java 1.7 and so on?
if above is false (i.e. you can mix versions), is above the preferred way? Does it make sense to run java EE 6 on java SE 1.8 (just an example)?
I know that Java EE is just a bag of specifications, but do these specifications enforce java SE version anyhow?
It's rather about which SE versions EE server can work with. Like here https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Installation_Guide/Java_Environments_Supported_By_JBoss_Enterprise_Application_Platform_61.html
As per oracle document here
Java EE
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.
So ideally Java SE must be higher or equivalent version when compared to JAVA EE. According to this statement its possible to run java EE 6 on java SE 1.8 and not the other-way round.
I am going to develop enterprise apps towards a WebSphere 8.5 server. WebSphere 8.5 works with Java EE 6 and Java SE 7.
So what does that mean as far as code development goes? Is Java EE just a set of additional enterprise libraries? Does Java EE 6 mean it uses Java 6 syntax? Can I use Java 7 syntax on an 8.5 server and still utilize the frameworks and webservices provided by Java EE 6?
Java EE is actually a set of specifications of various technologies. Each spec typically has an API (eg: javax.servlet.*, javax.ejb.* etc which is implemented by various vendors (eg: IBM websphere, JBoss, Weblogic etc). The idea is you only learn and write your code once, but you can use your code (with some adjustment) and your knowledge on various vendor implementation.
When you compile your war you typically have to include (for compilation purpose only -- not necessarily packaged) java ee api component of a particular version on your classpath (eg: java-servlet-2.5). The API component often has dependency to particular version of Java SE (eg: if the API / vendor implementation uses generics, it requires Java SE 5 or higher)
Java EE is required to be backward compatible, hence if you compile and package your war against Java EE 6 API, it will run on Java EE 7 container.
You don't necessarily have to use Java SE 7 API to run your code on Java EE 7, you can always compile your war against older version of Java EE API (hence older Java SE). New features will only available if you compile against latest version of the API.
Java EE specifications do target a specific Java SE release. For example, JSR 316 says: Java EE 6 is the Enterprise Edition of version 6 of the Java platform, and thus will be built on Java SE 6. Individual specs may still choose to be compatible with lower versions of Java SE, but never a higher version. Whether a Java EE implementation actually runs on a higher Java SE version that it was specced for depends on the implementation.
by #Arjan Tijms
So what does that mean as far as code development goes?
It means, that you should know Java SE to create apps with the Java EE standard. Java EE is based upon Java SE.
Java SE 7 tutorial
Java EE 6 tutorial
Is Java EE just a set of additional enterprise libraries?
Well, simplifying many things... Yes.
Does Java EE 6 mean it uses Java 6 syntax?
Can I use Java 7 syntax on an 8.5 server and still utilize the frameworks and webservices provided by Java EE 6?
You can use Java SE 7 syntax in Java EE 6 apps. But you can use Java SE 6 syntax too.
When I create a new enterprise application project in Netbeans 7.2.1, the IDE shouts out a recommendation: "Source Level 6 should be used in Java EE 6 projects".
Have a look at this screenshot:
Screenshot of Netbeans IDE 7.2.1 http://www.tinyuploads.com/images/Qs9Doh.png
Why is this practice recommended? Any reason not to follow the advice?
If you want to produce portable applications, Java SE 6 is the base on which Java EE 6 is defined.
From JSR 316: JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification:
EE.2.4.1Container Requirements
This specification requires that containers provide a Java Compatible™
runtime environment, as defined by the Java Platform, Standard
Edition, v6 specification (Java SE).
However, if you have a vendor-specific target Java EE 6 platform built on a newer version of Java you should often use its JDK as the target.
There's a trade-off between portability and being able to take advantage of container-specific features in enterprise development. NetBean's conservative recommendation is the correct option for those who don't know enough to make their own decision.