Java is the language, the JRE is the runtime environment, and the JDK are the development tools? The JLS is the spec that says that the JRE must do x,y,z, and therefore makes Java what it is? Are these views correct, and if not can someone enlighten me?
Are there any things we think are Java but are not? I think I heard that about Android -- is it true?
To some extent this is a problem of the ambiguity of natural language; some of these things can mean different things at different times.
"Java" can refer to the Java language, as in "I wrote this amazing FooWidget in Java." It can also be shorthand for the Java platform including the language, runtime, tools, etc., as in "You'll need Java to use this web application."
JRE stands for Java Runtime Environment and is the bundled set of APIs included with the Java Virtual Machine. The JDK, or Java Development Kit, is the set of developer tools including the Java compiler, debugger, javadoc compiler, etc. Confusingly, it also includes a JRE (as seen in Eclipse, for example, where the JDK can be specified as the runtime for a project).
The Java Language Specification (JLS) is, um, the spec for the Java Language. Put another way, it describes the technical details of how the language is implemented.
Android is a platform in which the code is written in Java, but compiled to run on the Dalvik virtual machine rather than the JVM. In that sense, it isn't actually Java, but from the perspective of the developer the difference is mostly library use; the syntax is the same.
Similar questions:
JDK/JRE/JVM/Java SDK | What do they
all mean? Sometimes you can develop
with JRE and sometimes you need
JDK?
What does the JRE consist
of ?
Java specification
Related
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.
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 JVM open source code? If not, how can I get the code of JVM?
It depends entirely on which JVM you use.
If you use the OpenJDK JVM, then you can get the source code from here (or here from a list of OpenJDK projects).
If you use the Kaffe JVM, you can get the source from here.
If you use the Sun JVM version 6 or later, then you can get the source from here.
If you use a Sun JVM earlier than 6, then you can often get the source under an academic license. If you use an IBM, Oracle, HP, or other JVM, then the source is not open.
Update May 2013
The Version 6 source can still be accessed by the above link, or it can be accessed via this link. This latter link also includes a handy genealogy table that shows how the Oracle JDK and OpenJDK versions match with each other.
Additionally, a more up to date version of the Java 7 source can be found here. This also includes the fixes for the releases of Java 7 since GA.
And, of no surprise to anyone, the Java 8 sources can be found here.
Have a look at hotspot JVM here: http://openjdk.java.net/groups/hotspot/
The core part of the JVM is in the hotspot module of the OpenJDK. However what you need is more likely to be in src.zip.
The hotspot module apart of those classes is
mostly in C++
not always easy to understand. This has improved over the years and new code tends to be better as they are more aware that the code will have broader consumption.
often not what you are looking for.
For this reason if you want to know how the JVM runs it is best to look at the commonly used classes. For example, even something as low level as how lambdas really work at runtime is mostly in the src.zip not much is in the JVM.
Most of the source for the libraries come with the JDK in the src.zip file. Your IDE will use that automatically. You are much better off being familiar with the classes in these libraries than playing with the JDK itself.
There is no open source jvm even if there were you can't bypass Oracle's stupid classpath exception. In short openjdk is still tied to $$ driven scheme that forces you to contend with a comercial vm. No different from Microsoft really, you can work with C# under what ever os they even provide .net libraries free but maintain control over Visual Studio which practically forces the end user to make use of Windows as the chosen environment.
The compiler display warnings if you use Sun's proprietary Java classes. I'm of the opinion that it's generally a bad idea to use these classes. I read this somewhere. However, aside from the warnings are there any fundamental reasons why you should not use them?
Because they are internal APIs: they are subject to change in a undocumented or unsupported way and they are bound to a specific JRE/JDK (Sun in your case), limiting portability of your programs.
Try to avoid uses of such APIs, always prefer a public documented and specified class.
The JDK 6 Documentation includes a link titled Note About sun.* Packages. This is a document from the Java 1.2 docs, so references to sun.* should be treated as if they said com.sun.*
The most important points from it are:
The classes that Sun includes with the
Java 2 SDK, Standard Edition, fall
into package groups java.*, javax.*,
org.* and sun.*. All but the sun.*
packages are a standard part of the
Java platform and will be supported
into the future. In general, packages
such as sun.*, that are outside of the
Java platform, can be different across
OS platforms (Solaris, Windows, Linux,
Macintosh, etc.) and can change at any
time without notice with SDK versions
(1.2, 1.2.1, 1.2.3, etc). Programs
that contain direct calls to the sun.*
packages are not 100% Pure Java.
and
Each company that implements the Java
platform will do so in their own
private way. The classes in sun.* are
present in the SDK to support the Sun
implementation of the Java platform:
the sun.* classes are what make the
Java platform classes work "under the
covers" for the Sun Java 2 SDK. These
classes will not in general be present
on another vendor's Java platform. If
your Java program asks for a class
"sun.package.Foo" by name, it may fail
with ClassNotFoundError, and you will
have lost a major advantage of
developing in Java.
Try running your code with a non-Sun JVM and see what happens...
(Your code will fail with a ClassNotFound exception)
Yes, because nobody guarantees that these classes or API will be the same with the next Java release and I bet it's not guaranteed that those classes are available in Java versions from other vendors.
So you couple your code to special Java version and loose at least portability.
Sun's proprietary Java classes are part of their Java implementation not part of the Java API their use is undocumented and unsupported. Since they are internal they can be changed at any time for any reason that the team working the Sun JVM decides.
Also Sun's Java implementation is not the only one out there! Your code would not be able portable to JVMs from other vendors like Oracle/BEA and IBM.
Here is Oracle's answer: Why Developers Should Not Write Programs That Call 'sun' Packages
I recently had a case that showed a real-world problem you can hit when you use these classes: we had code that would not compile because a method it was using on a sun.* class simply did not exist in OpenJDK on Ubuntu. So I guess when using these classes you can no longer say things like 'this works with Java 5', because it will only work on a certain Java implementation.
Is JVM open source code? If not, how can I get the code of JVM?
It depends entirely on which JVM you use.
If you use the OpenJDK JVM, then you can get the source code from here (or here from a list of OpenJDK projects).
If you use the Kaffe JVM, you can get the source from here.
If you use the Sun JVM version 6 or later, then you can get the source from here.
If you use a Sun JVM earlier than 6, then you can often get the source under an academic license. If you use an IBM, Oracle, HP, or other JVM, then the source is not open.
Update May 2013
The Version 6 source can still be accessed by the above link, or it can be accessed via this link. This latter link also includes a handy genealogy table that shows how the Oracle JDK and OpenJDK versions match with each other.
Additionally, a more up to date version of the Java 7 source can be found here. This also includes the fixes for the releases of Java 7 since GA.
And, of no surprise to anyone, the Java 8 sources can be found here.
Have a look at hotspot JVM here: http://openjdk.java.net/groups/hotspot/
The core part of the JVM is in the hotspot module of the OpenJDK. However what you need is more likely to be in src.zip.
The hotspot module apart of those classes is
mostly in C++
not always easy to understand. This has improved over the years and new code tends to be better as they are more aware that the code will have broader consumption.
often not what you are looking for.
For this reason if you want to know how the JVM runs it is best to look at the commonly used classes. For example, even something as low level as how lambdas really work at runtime is mostly in the src.zip not much is in the JVM.
Most of the source for the libraries come with the JDK in the src.zip file. Your IDE will use that automatically. You are much better off being familiar with the classes in these libraries than playing with the JDK itself.
There is no open source jvm even if there were you can't bypass Oracle's stupid classpath exception. In short openjdk is still tied to $$ driven scheme that forces you to contend with a comercial vm. No different from Microsoft really, you can work with C# under what ever os they even provide .net libraries free but maintain control over Visual Studio which practically forces the end user to make use of Windows as the chosen environment.