When we use java -fullversion, we get output like java full version "1.7.0_45-b18".
what is this b18 in java full version?
I went thorough some oracle java articles which says that it is indicates build versions. So what is this build version supposed to be?
Also I see that some bugs on http://bugs.java.com/ which says that they are backported from higher version. For example : http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8018840
It says that "Affected Versions: 7u45" and "Fixed Versions: 7u45 (b01)".
So what is this Fixed Versions: 7u45 (b01) indicates? Does this mean it is fixed in some later build of same java version?
Also as my current java -fullversion command says : "1.7.0_45-b18". SO does it mean that there are 18 different build for 7u45?
b18 does not refer to having 18 builds in your system.
The concept is like:- Once code completion is done by developers on few features of the software, the lines of code is converted to a software or application so that we can use it.
Each Build is numbered and it keeps changing with every release of that new version.
So b18 has all previous features and new features included i.e an updated version of the software and your OS will update the software(if automatic update is enabled) rather than keeping copy of each build.
Hope this clarifies your doubt to some extent... :)
From the Javadoc source:
JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_45
6 1.6.0_65
5.0 1.5.0_55
So as you have already found b means the "build" and 1.7.0_45 is the JRE Security baseline which represents JRE Family Version 7. And b18 is the Build 18.
Related
I have a Spring Boot application and I'm trying to set the JDK to OpenJDK-17. I've downloaded it from Java, then I go to IDE and Project Settings > Project Structure > SDKs, and then I click on the '+' > Download JDK. Then when I set the version to 17, I don't see OpenJDK-17 anywhere...
I get the following options:
Amazon Corretto 17.0.6
Azul Zulu Community 17.0.6
BellSoft Liberica JDK 17.0.5
Eclipse Temurin (AdoptOpenJDK HotSpot) 17.0.5
GraalVM Community Edition 17
IBM Semeru (AdoptOpenJDK OpenJ9) 17.0.5
SAP SapMachine 17.0.5
---------Other Versions---------
Oracle OpenJDK 19.0.2
I don't know for sure the rational of the Intellij for (no longer?) including a link to a "vanilla" OpenJDK 17 download site. However my guess is that it is related to this notice on the https://jdk.java.net/17/ release page:
JDK 17 Releases
JDK 17 has been superseded. Please visit jdk.java.net for the current version.
Older releases, which do not include the most up to date security vulnerability fixes and are no longer recommended for use in production, remain available in the OpenJDK Archive.
Note that the OpenJDK team are no longer publishing new builds for OpenJDK 17. If you want the current Java 17 LTS build, you get it as an Oracle release or you get it from a 3rd-party vendor. These should all include the most recent security patches.
The Intellij team would be doing users a disservice if they provided an easy way for users to download an old and potentially insecure OpenJDK Java 17 build.
OpenJDK is basically a source only project (though they do release reference binaries for the first six months, which usually results in three releases, e.g. 17.0.0 - 17.0.2). After those three months, newer releases are only available through the vendors (e.g. for Java 17.0.5). All those listed are variants of OpenJDK 17 (except IBM Semeru, which is OpenJ9, which itself is a variant of OpenJDK). And bar vendor specific extras, or optional features like garbage collectors, they are basically the same, and have been tested for compliance with the Java specification.
In the Java world, you pick a vendor, and use its binaries instead of the binaries from OpenJDK itself (which generally don't go further then x.0.2, while vendor specific versions continue to receive updates if they are LTS versions). Personally, I usually use Eclipse Temurin builds.
I just downloaded the Oracle OpenJDK 17 GA LTS release and installed it into IntelliJ. I've selected the jdk v17 as my Project SDK and am attempting to set my project language level also to v17, but the only choices are version 1.3 thru 16, along with an SDK Default of "X - Experimental Features". Where is language level version 17?
Basic support for Java 17 is available in IntelliJ IDEA 2021.2.1
Should have realized this sooner, but it turns out that the language level in IntelliJ is a function of the actual language support that the current version of IntelliJ has built in and does not come from the JDK. My IntelliJ version was 2021.1.3. I upgraded to 2021.2.1 and the basic 17 language support appeared. More JDK 17 support to be added later per this article on The IntelliJ IDEA Blog.
Quoting the okhttp github page:
The OkHttp 3.12.x branch supports Android 2.3+ (API level 9+) and Java 7+
But looking at com.squareup.okhttp3:okhttp:3.12.12 (seems to be the latest 3.12.x release at the time of writing), we find the following:
import java.time.Duration; // OkHttpClient.java line 23
and various uses of Duration which is a java 8 feature. This makes my code break at runtime with a:
java.lang.ClassNotFoundException: java.time.Duration
when running with:
java version "1.7.0_251"
Java(TM) SE Runtime Environment (build 1.7.0_251-b08)
Java HotSpot(TM) 64-Bit Server VM (build 24.251-b08, mixed mode)
which is a hard requirement in my target environment.
Is there in fact a java 7 compatible decently recent version of okhttp?
The way I read the tea leaves (as in not the docs) is that the 3.12.x branch is mostly there to support android where I assume things might be slightly different and packages like java.time are actually available in java 7 under certain conditions.
Assuming it is actually not possible to use okhttp 3.12.x from java 7 (normal, not android), it might be good to update the docs to reflect this to save somebody else the explorative journey I just went through.
< edit - comment added after response by yuri >
I created a gist with a stack trace here. The breaking statement on line 53 is:
client = new OkHttpClient.Builder()
.addInterceptor(interceptor)
.build()
(removing the addInterceptor call does not fix the problem)
Also it should be noted that this is a small, two-class project which I'm building with java 11, then using the mechanics in later versions of gradle (and java) to target java 7 and finally executing the fat jar with the above java 7 version. Quoting the gradle description:
Since version 9, the Java compiler can be configured to produce bytecode for an older Java version while making sure the code does not use any APIs from a more recent version.
So I'm building with:
------------------------------------------------------------
Gradle 6.6
------------------------------------------------------------
Build time: 2020-08-10 22:06:19 UTC
Revision: d119144684a0c301aea027b79857815659e431b9
Kotlin: 1.3.72
Groovy: 2.5.12
Ant: Apache Ant(TM) version 1.10.8 compiled on May 10 2020
JVM: 11.0.7 (Amazon.com Inc. 11.0.7+10-LTS)
OS: Mac OS X 10.15.5 x86_64
and running with the above mentioned oracle java 7.
The reason I'm building with java 11 is that building with java 7 forces me to downgrade gradle and a number of plugins to ancient versions and just generally becomes a mess. Possible, but would be nice not to.
Answering my own question. After some feedback from the okhttp devs on an issue created for this at:
https://github.com/square/okhttp/issues/6221
it seems that this issue is caused by groovy's use of reflective access / introspection.
I added the CompileStatic annotation:
https://docs.groovy-lang.org/latest/html/gapi/groovy/transform/CompileStatic.html
to the method exhibiting the issue and the issue is now gone.
We are planning to migrate our project from Oracle JDK to OpenJDK. I have some questions regarding the same.
After doing some analysis I found that OpenJDK will have a feature release every 6 months which is only supported until the next feature release.It's essentially a continuous stream of releases targeted to developers. Now my question is will it be a good idea to migrate to OpenJDK. Because if the
above statement is correct then we need to upgrade OpenJDK in our application every 6 months
Ref : Differences between Oracle JDK and OpenJDK
What are the basic changes required to do this migration. When I say basic changes, I mean I need to understand in very high level.One thing I know that is
Oracle JDK and Open JDK are having different jar licences. So do I need to replace all Oracle JDK jars with OpenJDK jars as its mentioned in
Migrating to OpenJDK from Oracle JDK ?
Currently we are using :
JDK 1.8
Tomcat 8
Windows Operating System for development. Services gets deployed in linux OS
Maven Build tool
Appreciate your help.
Thanks
Now my question is will it be a good idea to migrate to OpenJDK
For Java 11 you might want to, though by Java 11 they will be almost identical.
So do I need to replace all Oracle JDK jars with OpenJDK jars
I would install a version of OpenJDK and use the JARs which came with it. I wouldn't mix and match them.
JDK 1.8
I am not sure gain anything by migrating Java 8. Oracle Java 8 is still supported at least until Jan 2019. After that, you might not get any update, but you might not with OpenJDK either.
If your concern is getting support for Java 8, I suggest contacting a company which will give commercial support Java 8 such as Azul for what seemed like a reasonable price. https://www.azul.com/downloads/zulu/zulu-windows/
I installed java 8 on Lubuntu 13.10. It is pre release but it should work - JDK™ 8 Early Access Releases.
I added JDk to eclipse:
And tried wrote first java 8 version code.
This code should find the longest word.
I caught a bunch of exceptions:
for 12 line - it shows:
Multiple markers at this line
- Syntax error, parameterized types are only available if source level is 1.5 or
greater
- Resource specification not allowed here for source level below 1.7
Why does this exactly happen?
How to solve this trouble?
Eclipse JDT environment -- editors and tools -- only supports Java Syntax up to 1.7. As of today, Java 1.8 support is only available in early access releases.
Adding a JDK or JRE to Eclipse does no change the characteristics of the JDT environment, which is a highly-integrated set of tools. So, until Eclipse releases Java 1.8 support and that makes its way into your distribution, you will not be able to use the Java editor for any syntax that is unique to Java 1.8.