I want to know why JDK 9 no longer has the Java EE version. I was reading that since the JDK 9 version no longer has Java EE, then Java EE's own functions would appear as deprecated. Do you know how to solve this problem?
I want to know why JDK 9 no longer has the JAVA EE version.
Java EE / J2EE was never part of Java SE releases (JDK / JRE). While the version numbering was similar, this was largely a "marketing thing". Certainly the SE and EE release cycles were not the same.
Anyway, Oracle has passed control of Java EE over to the Eclipse Foundation; see Jakarta EE 8: The new era of Java EE explained
I was reading that java ee's own functions would appear as deprecated.
If someone actually wrote that Java EE is dead or "deprecated", they are incorrect. (Or at least, they are out of date.)
Java EE has now become Jakarta EE, and Jakarta EE has a clear future (see link above)
Even if it didn't have a clear future, that wouldn't amount to deprecation.
Do you know how to solve this problem?
I don't think there is a problem to solve.
The reality is that Oracle had lost interest in Java EE1, and progress under Oracle's stewardship had ground to a virtual halt. Jakarta EE is effectively a reboot.
While predicting the future is difficult, there are reasons to believe that both Java/Jakata EE vendors and Java EE/Jakata users will be better of with the new model. The first test will be the upcoming Jakarta EE 9 release which is scheduled for August / September 2020. (Check the Jakarta EE 9 home page for the latest news on the schedule.)
This Eclipse newsletter from last year gives a taster of what should be in the release:
Jakarta EE 9 - 2019 Outlook
1 - Java EE / Jakarta EE is essentially a set of specifications. Writing and maintaining high quality specifications is expensive. Since Oracle didn't have any significant (money making) Java EE products, Oracle management decided that it was not worth continuing to invest in that aspect of Java. Passing control to an other organization was the responsible thing to do. The renaming was necessary for legal reasons; e.g. protecting Oracle's Java trademark.
Related
So I'm trying to understand which JDK versions are compatible with Jakarta EE 9.1 (using glassfish 6.1.0). Apparently it supports up to JDK 11 but in NetBeans in able to perfectly run GlassFish with JDK 16 installed. Also it shows that the installed Jakarta API libraries are of version 9.0.0 but somehow I'm still able to download, install and run GlassFish 6.1.0..
To put it simply, I'm just really confused with all the version compatibility and how can stuff work on my end without matching versions (under the assumption that what I wrote above is correct).
Any product compliant with Jakarta EE 9.0 is guaranteed to work with Java 8.
Any product compliant with Jakarta EE 9.1 is guaranteed to work with Java 11.
Some products work well with later versions of Java as well.
Java 8, 11, and 17 are the official Long-Term Support (LTS) versions. So these are the versions expected to be used in production for serious deployments.
The main point of Jakarta EE 9.1 is the support of Java 11. Some specs have other changes, but mostly minor.
Jakarta 10, under development now, is where you can expect to see innovations and improvements. You can find many video presentations and blog posts discussing possible changes and current plans. The various teams are asking for input from those with an interest in their particular spec.
You said:
able to perfectly run GlassFish with JDK 16 installed
Java 16 is now at end-of-life, no longer supported. I suggest you move on to Java 17, the current version, and also a LTS version.
Yes, many products will run well with later versions of Java. This is especially true of products compliant with Jakarta EE 9.1, aimed at supporting Java 11. Java had some issues with breaking or limiting backward compatibility between Java 8 and 11. So some older products may run into a problem when moving past Java 8. In contrast, compatibility from Java 11 through 17 has been very smooth with very few issues.
But that is the point of the six-month cadence of official Java releases. You can, and likely should, do some of your dev and testing work using each Java release. If you encounter any issues, you can provide feedback to the developers of the problematic product sooner rather than later.
Regarding Eclipse GlassFish specifically, their home page describes various releases.
Version 6.2.2 is the current release compliant with Jakarta EE 9.1.
Compiles with JDK 11 to JDK 17
Runs on JDK 11 to JDK 17.
Briefly tested with JDK 18 early-access releases.
The prior version, GlassFish 6.2.1, brought much improved support for JDK 17.
I would like to add scripting capability to events in an existing Java application. Looking about, I find JSR 223 for Java scripting. But it is withdrawn, and wikipedia tells me that
it was decided that this functionality would be included as an integral part of Java 9 and onward.
Yet looking at the wikipedia page on Java SE versions I see nothing from Java SE 9 onward to the present time (Java SE 16, under development) that sounds like "scripting" to me.
So what is the current recommended approach to integrate a scripting facility into an existing Java program? (And did I miss something in Java SE 9+ that speaks to this?) (Or does the fact that it does show up in Java SE 8 on that wikipedia page mean that it actually got in "early" - for some definition of "early" that includes being in a late release ...)
I think you can ignore the withdrawn status, especially because it's already working/embedded to Java
I'm looking at your wiki link and it states that JSR 223 in on Java SE 8
JSR 223, JEP 174: Project Nashorn, a JavaScript runtime which allows developers to embed JavaScript code within applications
and even Java 6:
Scripting Language Support (JSR 223): Generic API for tight integration with scripting languages, and built-in Mozilla JavaScript Rhino integration.
Actually there were enhancements since Java 7
Enhancements in Java SE 7
The JDK 7 release is co-bundled with the Mozilla Rhino JavaScript engine based on version 1.7R3 pre-release sources with Oracle modifications. You can download the Oracle modified Rhino sources at java.net.
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.
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.
This question already has answers here:
Getting Started With Java EE [duplicate]
(3 answers)
Closed 8 years ago.
I'm planning to study Java EE but I do not know where to start.
Based on Java EE version history there are technologies present in lower versions which are not available in the higher version. Do I need to learn J2EE 1.4 before learning Java EE 5 or 6? Or is it better to learn the latest version since their purpose of doing it is to improve the previous version.
Can you also suggest some resources on Java EE?
Unless there is a direct need to work on a legacy system, it is perfectly fine to start with the newest version of the Java EE standard.
For starters I'd recommend free tutorials by Marty Hall, especially Configuring & Using Apache Tomcat to get you up and running.
There is also an official Java EE beginners tutorial, The Java EE 7 Tutorial. It is decently written and contains a lot of examples. By the end of it, you should have a pretty good idea where to go next.
As Saul explained, unless you need to work on a legacy system, there is not a single reason to learn an older version of Java EE.
Every version of Java EE is a fully contained platform and doesn't require learning or knowing anything about the previous versions.
In case of 1.4, it's even better to avoid it at all cost. It contains several technologies (mainly EJB 2), that are the embodiment of bad practices. Looking at those will serve no other purpose than to cloud your mind. If possible, stay away from it.
Java EE 6 is a radical departure from the way applications were build in 1.4, and is the recommended version to start working with.
Oracle Java EE Tutorial is the best for beginner. In Java EE scope. there are many frameworks,such as JSP,JSF,Servlet,Spring,Struts and so on.First you should try to focus which framework is more suitable for you and then try to learn it first.
In my opinion, you need to learn J2EE 1.4 before learning Java EE 5 or 6 is good because sometimes we may face to maintain legacy Java EE systems.
But you have no need to maintain legacy systems then you should learn Java EE 6 first.