We Keep Coding

How does Jakarta/Java EE compatibility work?

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.

Deprecated Java EE in JDK 9 and later versions

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.

Can I use any version of Java SE with Java EE 8?

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

What do the Java versions mean in Websphere?

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 JSF 2.0 will be released?

I got interested in looking at JSF 2.0 as a potential technology to use. Does anybody know when this version is scheduled to come out and how active is the project in general?

Does anybody know when this version is scheduled to come out
JSF 2.0 is part of Java EE 6 (i.e. any Java EE 6 container supports it) and has been elaborated under JSR-314 (which is final since 01 Jul, 2009) but, as mentioned on the JCP web page:
Sun will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK). The RI will be made available standalone and as part of the Java EE 6 platform.
The RI is Mojarra and is already available. As written in Mojarra 2.0.0 is available! (Oct 19, 2009):
There are several ways to obtain the
release.
GlassFish V3 promoted build 69 (out later this week)
Download directly from http://javaserverfaces.java.net
Download using Maven2 using information provided here
You actually don't need a full Java EE 6 server. For example, check out the post JSF 2.0 and Tomcat or Integrating JSF 2.0 and Weld with Tomcat6. But I'd simply go for GlassFish v3 (or JBoss 5.2+ which also supports JSF 2.0 + CDI).
how active is the project in general?
What project? The RI? What do you mean exactly? Well, Mojarra is used in GlassFish so I consider it as a serious project, with dedicated man power. However, I don't expect extreme activity now that the spec is final, only maintenance and bugfix releases.

JSF 2.0 was already final several months ago (19 october 2009) and it's indeed included in the Java EE 6 which was made final about one month ago (10 december 2009).
Although it's been released along with Servlet 3.0 API in Java EE 6, JSF 2.0 is backwards compatible with Servlet 2.5. So you can either download it separately and run on any Servlet 2.5 capable webcontainer like Tomcat 6.0, or just download a full fledged Java EE 6 implementation including it like Glassfish v3.

JSF 2.0 is included in Java EE 6, and Glassfish v3 currently supports it. It'll also run in WebSphere 7, with some effort.