I've seen three possible Java version notations, e.g. Java 8 may be written in the following ways:
Java 8
Java 8 SE
java 1.8
Which is the correct one? I mean which one is usable in academic writing?.
Similar problem with JDK and JRE
If you are writing about Java Standard Edition, then the correct notation will be: Java SE 8, the same rule applies for Enterprise Edition (Java EE 7).
Java 8 and Java 1.8 are the same and Java 8 SE is standard Edition. Java 8 is good for academic writing.
The Java naming and versioning convention is unfortunately complicated. In fact, java versioning has its own Wikipedia page.
Versioning
Java started off its life in 1.0 and 1.1 in the mid 90s. When Java 1.2 was releases it was branded as "Java 2". We had to live with the next few releases with this dual numbering scheme until Java 1.5 when the "1." prefix was dropped and 1.5 officially became 5.0.
Java 8 being referred to as "Java 1.8" is an artifact of this history.
Java Editions
Java SE, the Java Platform, Standard Edition (also known as J2SE until Java 5) is the Java platform used for java desktop and server programs. Java SE is what most people mean when talking about Java.
Other "Editions" are Java ME (Micro Edition) which is a cut down version of Java for embedded devices (including phones) and Java EE (Enterprise Edition) which provides extra libraries on top of Java SE including Java Servlets, EJB, JMS and others used in Java Application Servers.
JRE vs JDK
JRE: Java Runtime Edition
JDK: Java Development Kit
Simply, the JRE is able to run Java progams; the JDK is used to build Java programs.
See Also
Why java is now known as java2?
What is the difference between JVM, JDK, JRE & OpenJDK?
Three of them are valid notations. There is no right or wrong all of them are used.
I don't think using either one of the options should make any difference. All convey the same thing and anyone using Java will know this.
However if you are concerned about academic writing then you can use
Java SE 8
and give reference as Wiki link :)
As per the java spec, java versions can be denoted as java 1.x.x
Java Standard edition (correct notation is Java SE 7)
JDK version can be represented as JDK 1.x.x, similar to JRE as x.
(If the version of JDK is (1.7.0) then the JRE version to be 7)
Related
Here's the thing:
Me and my teammates are now working on a Java project, but I'm almost new to Java development. The thing is that I recently updated my local Java version to 15.0.2, however, they created the project with JDK 1.8 (Java 8 perhaps?).
We are worried that this might cause some conflicts since our Java versions are not corresponding, and I'm also not familiar with the relationship between Java version and JDK version (Just like Java 8 and JDK 1.8).
Could somebody give me some explanations of this? Thanks a lot!
We are worried that this might cause some conflicts since our Java versions are not corresponding ...
Yes, you could run into problems:
There are significant differences in the Java language and Java standard class libraries between Java 8 and Java 15. Code written for Java 15 using Java 15 may not compile on Java 8.
Java 8 and Java 15 tool chains produce compiled code with different classfile version numbers. Code compiled for Java 15 will not run on a Java 8 platform.
It is possible to work around these problems, but it is much simpler if all project members use the same Java version.
If you are new to Java, my recommendation is to install and use Java 8. Note that it is possible to have different versions of Java installed simultaneously, and use different versions for different projects.
... and I'm also not familiar with the relationship between Java version and JDK version (Just like Java 8 and JDK 1.8).
It is pretty straightforward. Java 8 is JDK 1.8, Java 9 is JDK 1.9, and so on. This started with Java 5 / JDK 1.5
The weird numbering is a result of a Sun Management / Marketing decision when naming Java 5:
"The number "5.0" is used to better reflect the level of maturity, stability, scalability and security of the J2SE."
Source: https://docs.oracle.com/javase/1.5.0/docs/relnotes/version-5.0.html
(You could also say that the people who made this decision didn't understand the principles of semantic version numbering.)
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.
I've been reading about differences between Java SE and Java EE. And everything it seems to be ok. But It seems doesn´t exists a Java EE JDK, is only a Java EE SDK.
Java EE 8 Platform SDK:
Java SE Development Kit
What is it that I am not understanding about Java EE and SE?
I read
Is there a Java EE JDK
but in simple words, why doesn't exist Java EE JDK?
To develop my comment, Will Hartung made a very good summary here:
Java SE -- Java Standard Edition, it happens to come in two versions: the JDK and JRE. JDK has the compiler and other tools.
Java EE -- Java Enterprise Edition is simply a standard, and a couple of libraries consisting mostly of just interfaces.
To put it simply, I used this analogy:
[The] question is like "there are cars and trucks. Why there is only garage and not garage for trucks? Because if you fix a car, you can fix a truck (more or less ^^)"
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.