We Keep Coding

Whether Java SE is the same as JDK? [duplicate]

This question already has answers here:
Java JDK, SDK, SE?
(4 answers)
Closed 5 months ago.
Me has been fighting with internet for a while for that single answer. Everything else now seems standing on it's place after this trip.
When I ask "What's Java SE" they say "Java SE is set of core Java classes ...... platform ... develop desktop apps .... contains core libraries and APIs ..... Java EE is a spec set to be implemented ...... Java EE is built on top of the Java EE". Sometimes they mention javac and JVM, sometimes they don't. What they do never (almost) is mention JDK.
When I ask "What's JDK" they say "JDK is set of stuff that lets us build apps on Java including javac, JVM etc." and never (almost) mention Java SE.
When I ask "Difference between Java SE and JDK" they give me that page and nothing more to think about. What does this mean: "Java SE product name for JDK"? Can't clearly understang right now.
Lack of terminology presicion and experiece for me? Possibly yes. I think would be able to answer this question myself if I were more experienced.
The questions:
"Whether (Java SE) == (JDK) or not?" (pls with wide explanation and terminology clarifications when needed).
Is Java SE a spec set like Java EE or not?
Can I find precise definitions somewhere to look at?
Sorry for a big writing. It proves that I would really love to put an end to this.

“Java SE” is three things:
An abbreviation of “Java Standard Edition”
A trademark owned by Oracle Corp.
A set of specifications published by Oracle Corp.
Anybody in the world is free to write software that implements the Java SE specifications. In the past, several companies have done so.
However, anybody in the world is not free to use the trademark of Java. To use that trademark, a person or company is required to come to terms with Oracle in a licensing deal. Presumably that deal would require payment.
Long story short, and over-simplified for brevity… Some of the companies that previously wrote their own implementations of Java SE decided to join forces, combine their codebases, and publish the whole thing as open-source. These companies included Oracle, IBM, and Apple. Thus was born the OpenJDK project (Wikipedia). Since then, other companies and individuals have joined the project.
The OpenJDK name is a trademark owned by Oracle. However, Oracle has published permission allowing others to use the term with no payment required.
The OpenJDK project published source code to an implementation of the Java SE specifications. The project does not publish built binaries or installers.
Several vendors do publish built binaries or installers for implementations of the Java SE specs. Nearly all of these implementations rely largely, if not entirely, in the OpenJDK source code.
These binaries/installers vendors include, in no particular order:
Azul Systems
SAP
Amazon
Microsoft
IBM
Red Hat
Oracle
Adoptium
BellSoft
… and more.
Most of those built binary or installers products use OpenJDK in their name or in their descriptions, as allowed by Oracle. A few of those products may use the term Java or Java SE with explicit permission from Oracle.
There are other editions of Java technology:
Java Card (for smart cards, badges, etc.)
Java ME, or Micro Edition (for constrained devices)
Java EE, or Enterprise Edition (a wide collection of specifications that run on top of an implementation of the Java SE specs, aimed at developers making software for enterprise oriented users)
The first two, Java Card & Java ME are owned by Oracle. The third, Java EE, was donated by Oracle Corp to the Eclipse Foundation were it is now known as Jakarta EE. Jakarta EE is a collection of specifications, with various vendors publishing implementations.
The term “JDK” refers to Java Development Kit. This kit includes an implementation of the Java SE specs, plus tools to write Java apps. These tools include a compiler.
The term “JRE” refers to Java Runtime Environment. This is a JDK minus some of the software development tools.
The term “JVM” refers to Java Virtual Machine. A JVM is a piece of software that enables a Java-based app to execute at runtime on a particular kind of host computer and operating system. Java apps are platform-agnostic, in other words, are not “native”. So a Java app needs a particular JVM to know how to run on a Mac, on a PC, or on a mainframe.
Every JDK and every JRE contains a JVM.

1 . Yes, you can think of Java SE same as JDK.
Java SE is the 'base' platform that defines the Java language specification (JLS), the Java Virtual Machine Specification (JVMS), Standard library APIs, byte-code format, compilation tools, and the class loader.
Now, this is all concepts and specifications and community proposals (via JCP) until implemented into a set of software tools. The set of software and tools that implements all of the above is called JDK.
JDK is essentially a Software Development Kit (SDK). They simply decided to name it JDK.
2 . Yes, Java SE is basically a set of specs. An implementation must follow the spec and get it reviewed & approved by Oracle before they can call their implementation Java.
In the case of Java EE the specifications deal with libraries & APIs most of the time. In case of Java SE the specs also care about language and VM details. You take Java SE (the standard JDK) + add some libraries and now you have Java EE. Oracle refers to this as Java EE SDK though.
3 . Unless your life depends on it. Just understand the relationship between Java SE, Java EE, JDK, SDK, and you are good. Just connect the dots and be done with it.

I think your confusion stems from what Java is. Originally, most languages were like C, where you write code, and it gets compiled to a specific computer architecture/ISA (x86, ARM, whatever).
Java "changed the game" when it came on the market, because it was:
Free (many langs at the time were proprietary)
Enforced object oriented programming style (which all the cool kids were doing at the time)
It added the JVM. The JVM is installed on top of the ISA, it was a piece of middleware that meant that compiled Java code could "run anywhere" (in practice, this isn't strictly true, but it's aside the point)
Anyways, if you just need to run Java programs, you can just install the JVM/JRE (of which the JVM is a component). If you actually need to develop Java programs, you need one of these "editions," which supports more or less features, depending on what you are doing with it. If you're a hobbyist programmer, SE is fine. SE, EE, and ME all include the JRE, JVM and JDK.

For a start here is the language specification (what's the meaning of for) itself and the JVM (Java Virtual Machine) specification. A JVM knows how to execute the code in the end. (see https://docs.oracle.com/javase/specs/)
"Java SE" is the "Standard Edition" as opposed to "Java EE" which is the "Enterprise Edition"
Enterprises create webservers so Java EE specifies many things needed for running Java based Webservers like how to respond to web requests. There also additional libraries and webservers that adhere to that Java EE spec but they are still written in Java, i.e. what you do with plain Java (SE). See https://www.oracle.com/java/technologies/javaee-8-sdk-downloads.html
To run any kind of Java program you you'll need a JRE (Java Runtime Environment) which is in a way part of Java SE because it bundles all the core functionality of Java. The core libraries (like the implementation of the String class) as well as a JVM implementation (Oracle, OpenJDK, ...). Even an EE webserver would still require a JRE to run.
If you want to develop a Java program, you will also need a JDK (Java Development Kit) which is essentially a JRE plus extra tools, the compiler for example. The compiler takes .java files and create .class files which is what the JVM needs.
It's also in a way part JavaSE but I wouldn't says JavaSE = JDK.
Java SE and just "Java" is probably the same, the other terms all go into different aspects of Java.

is java 9 and above still platform independent or not after this module system has been introduced?

I am not able to understand that after module system is introduced in our java language. Is java9 and above still platform independent or not ? I am asking this question because I have read that now every application will have its own jre inside it. So, how will this single jre run on all OS, like windows, Linux, or Mac OS.

You are conflating two different changes recently made to the Java platform:
Retiring of Java Web Start & Applet technologies
Modularization
Retiring desktop-technologies
Recently Oracle announced the phasing out of the Java Web Start technologies, in addition to the already-deprecated Applet technology. See item JDK-8184998 in Java 9 Release Notes:
Java Deployment Technologies are deprecated and will be removed in a future release
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.
End-users will no longer be encouraged to install a JDK or JRE on their computer.
For more details, see the eight-page 2018-03 white paper from Oracle, Java Client Roadmap Update.
So then, how are developers of Swing or JavaFX apps to deliver their software to the end-user?
Oracle suggests packaging up your app along with a JVM & JRE for delivery as a single launch-ready applications on that appears on the client to be just another app alongside the native apps. Such “double-clickable” app-packaging has been commonly done on the Mac since the beginning of Java. But what was once an obscure art on other host environments (Linux, BSD, Windows, etc.) will now be the norm, as it is on macOS.
In yesteryear, bundling a Java runtime with your app required jumping over some licensing hurdles. The legalities have eased with arrival of the open-source OpenJDK project, and possibly with other implementations†.
You will need to prepare different releases of your app for each hosting environment. While your Java code runs independently of the host OS, the JVM is built of native code to interact with one specific kind of host. So you will need to build a Linux release with a Linux JVM, a macOS release with a macOS JVM, and so on. While that may seem like a downer, the upside is that you no longer need to worry about users having the wrong JVM version installed, or no JVM at all. Now the JVM’s presence and version are under your control. Your end-users and customers will no longer need to be aware that your app is Java-based.
Modularization
That need for app-packaging has nothing to do with the modularization of Java. As I said, it has been done for decades on the Mac.
What modularization brings to the party is that the JVM/JRE you bundle into your delivered app can be customized to contain only the Java Modules actually utilized by your particular app. This results in a smaller size, so your finished app is smaller, downloads are faster, less storage is used, and your app may load faster.
The open-source jlink “Java Linker” tool helps with the packaging work, so you can assemble and optimize a set of modules and their dependencies (only the ones actually called by your app) into a custom run-time image. This modular run-time image format is defined in JEP 220.
† On a related note, you may want to read the white paper Java Is Still Free to understand how and where to obtain a Java implementation for your app, and what support may or may not be offered in either free-of-cost or paid releases.
By the way, you may find helpful this Answer on a related Question, with a flowchart of choosing various sources of a Java implementation.

Is java9 and above still platform independent or not ?
Yes. It's as platform independent as it ever was. The module system has nothing to do with platform independence.
now every application will have its own jre inside it.
It doesn't have to, but it's more and more recommended as time goes on since fewer people have Java installed separately on their systems. This used to be a given, but that number has been declining for the last decade or so, and now (outside of Java developers) pretty much no-one has a standalone JRE installed.
how will this single jre run on all OS
It won't. You will bundle a separate JRE for each platform you want to distribute for. But JRE's for all platforms are still freely available, and the same Java code will still run on a JRE for any platform.

The module system doesn't influence the OS independency of java in general. Java applications that make use of the module system need to be run in a JRE. This can be either an OS specific pre-installed JRE as usual or a tailored runtime image (application embedded JRE) created with JLink.
The module systems main purpose is to provide you a managed way to split your application into different logical modules. E.g. into different .jar files that can be loaded at runtime - no matter on which operating system.
In summary, you have the following options:
Make sure that your client has the right JRE pre-installed. This could be dangerous, because (normally) you are not in control of his updating behavior.
Ship your application together with an official JRE.
Tailor your own, application and OS specific runtime image using JLink. Ship it bundled with your application.
But, suppose I do not know what OS my client would be running so how
the server will decide what image he should give to him. i.e., a Mac
Image, a Linux Image or a Windows exe.
You have to know the target OS and deliver the right runtime image.

While Java 9 makes it easier to ship a JRE which is more compact and specific to the needs of an individual application, you are not required to do so. If you were already planning to ship a JRE with your application it can be smaller with Java 9 than earlier versions.
It doesn't mean you have to ship a JRE, an application which wasn't shipped with a JRE is unlikely to start shipping with one now, and in fact Java 11 only ships as a JDK.
From this link on Java 9 features;
JLink allows you to create custom runtime images that only consist of your application modules and those JRE modules that your application requires. The result is likely a smaller runtime image, which uses fewer resources than a default JRE.

Can I install java but not Java SE?

I've got a little question (just for a cultural purpose).
Would it be possible to download and install Java but not the standard edition ?
I know that Java SE contains basic and usefull functions / librairies (such as input /output).
Installing java without the "SE" is maybe useless and without any interest, but is it possible? if yes how ?
Many thanks,

Installing java without the "SE" is maybe useless and without any interest, but is it possible?
It is not possible. Oracle don't distribute a form of Java without libraries.
In fact, there is no such thing as Java without the libraries (SE or ME). The libraries are part of Java(tm) platform. If you managed to create something with the Java language and a JVM, but with partial, missing or incompatible libraries you couldn't call it Java1. Oracle owns the Java trademark, and they dictate the terms under which you are allowed to use it. If you used "Java" for a JVM / Library combination that doesn't pass the standard Java compatibility tests, you would likely get a "cease and desist" letter from Oracle's lawyers!
But more importantly, there is a significant subset of the Java SE runtime libraries that are essential for bootstrapping a JVM. If you were to build your own (ahem) Java build that left out critical classes, your JVM wouldn't work.
(And you cannot just simply2 write your own replacement for the Java SE library subset that the JVM depends on. There are many places where the C / C++ codebase for the OpenJDK JVM has intimate knowledge of the implementation details of the Java libraries. Figuring it all out ... from scratch ... would be challenging.)
Having said that, in Java 9 they introduced a tool called jlink which will produce a cut-down Java SE runtime for an application that only contains the libraries that are required by the application. Your can read about it here.
1 - For example, the Sun vs Microsoft lawsuit over Microsoft's attempt to "embrace and extend" Java 1.1. See What does Sun's lawsuit against Microsoft mean for Java developers?
2 - It's not impossible. Just a lot of really hard work.

The java command is traditionally from a SE installation. Typically in the JRE form, but occasionally I the JDK variation for advanced users. Others exist but are not for desktop usage.
So in that view you cannot install java without SE.
(note: Java EE is not a distribution as such but an API typically provides by big web servers)

Can I install Java but not Java SE?
Install? No. Not from any "official" distributions provided by Oracle, at least.
Why not?
Because Oracle doesn't package it that way. They offer 1) a Java SE development kit (JDK) which lets you create Java programs for yourself, or 2) a Java SE JRE which just lets you run Java programs that someone else created. There is no 3) Java without SE.
But couldn't they have given us option #3?
Could they have? Probably. Well, OK, maybe. Did they? No.
But theoretically it's possible, right?
Theoretically, I don't see why not. Theoretically, it ought to be possible to come up with a "Java" that's little more than a virtual machine and a compiler. Then, theoretically, using only this non-Java-SE Java language, you could either replicate the Java SE environment or develop an entirely new Java-based development platform.

Is the JVM a part of an OS or package?

I know Java Virtual Machine is used to run a java program independent of the OS.But can anyone tell me if JVM is the part of OS or a package.

Depends on your definition of OS, your definition of package and your actual OS.
Some OS vendors ship a JRE or JDK as part of their OS install in eigter core or extended sets. They all ship it as packages. This includes AIX, Solaris and some of the commercial Linux distributions.
However, without knowning your background it is safe to say it would be a stretch to consider Java to be a part of the OS itself. The one exception would be Android (however it is debatable if the Android VMs can safely be called Java :)
(Not talking about embedded and card os here).

Why java JDK gives option for all OS?

http://www.oracle.com/technetwork/java/javase/downloads/jdk-7u3-download-1501626.html
We know that java is a Platform Independent Language then why does this site provide JDKs for all OSes like Linux, Windows, Solaris?
Then why do we tell java is Platform Independent?

it is like this:
your application
---------------------
JAVA on OS1
---------------------
OS1
---------------------
hardware
---------------------
if you write your application on top of Java, then you can just move your java
application, as is, without changing it, or even compile it, to new OS, because
your program is written on one platform, which is Java, not the native OS.
So, you need to download specific Java for your OS. But from application point of view, it is the same API. Java makes your application platform independent since it hides the OS from your application. But Java itself, it has to be compiled and build for each specific OS. But the application do not care about that. The application sees the same API. That is the whole point.

Because there you download the Installer for the Java Virtual Machine. This is the environment where your Java Application is running in.
The reason why Java is OS independent, is because its running in this JVM.

The JVM's job is to hide the differences between platforms and to provide the same execution environment to application code regardless of platform.
The JVM is written in C++, and is compiled to a native binary, just like any other C++ application. (You wouldn't expect a .exe file to run on Linux, after all).
So the JVM is platform-specific, but the environment it provides is not.

To explain you in simple terms, you no need to compile your java source code when you move your code from one OS to another, but to run your compiled java code you need to have OS specific Java run time machine. Thats why you have different JDK for different OS.

To add to others answers, Java is qualified Platform independent because the code you write is supposed to works on every platform. That's not totally true in fact. The Java code is always compiled in bytecode in the same way, but the JVM interprets this common bytecode in different way in function of the OS, there is one JVM per OS. OS that don't have a JVM implementation to use bytecode can't support Java.