I'm using JBoss-4.2.3.GA with Oracle JDK 1.5.
However, I want to move to OpenJDK. So, what are versions of OpenJDK which integrated with the JBoss-4.2.3.GA?
Not with ancient Java 5. As per OpenJDK versions the OpenJDK project started with Java 7 and was retrofitted into Java 6 but there is no version for Java 5. OpenJDK is an almost exact copy of OracleJDK since Java 8, previous versions have known issues e.g. worse 2D graphics performance.
You could try updating to Java 6 which is supported as per JBoss 4.2.3 release notes but Java 6 is officially dead for two years now. Investing into dead technology is counterproductive.
Your best course of action is to update JBoss 4.2.3.GA to something recent, this version was released over ten years ago!
Related
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.
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.)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I wanted to install JDK 9 on my machine, visited JDK official download page, and was surprised to see,
Java SE 9 has reached end of support. Users of Java SE 9 should switch to Java SE 10. Please visit our Java SE Downloads page to get the current version of Java SE. You will be redirected to the Java SE Downloads page in ... seconds. Please update your bookmarks to the Java SE Downloads page.
I did some googling and Java release history etc. But couldn't find any concrete reason.
I have couple of questions-
Oracle is still supporting the JDK 1.8, but stopped releasing updates to JDK 9, why?
Should I continue using JDK 1.8 for some time and then directly switch to JDK 10?
In the past, Java major releases often tended to be loaded with far-reaching features that had a massive impact on the code that you could and should write, like generics (Java 5) and functional constructs (Java 8).
With Java 9 Oracle introduced a new modularization system (project Jigsaw), that also has a massive impact on the JVM architecture (although, not so much on the language syntax). They had to postpone the release of Java 9 two times because of disagreements on the implementation of that feature with other influential members of the Java community.
Presumably drawing a lesson from this, Oracle decided to overhaul the development style for Java to be more incremental or "agile", if you like. Instead of having feature loaded major releases that can sometimes take many years to finish, they want to publish major releases with less new features each in a fixed release schedule every six months.
Java 9 and Java 10 are the first two versions scheduled with this new release model and Java 9 already got deprecated with the release of Java 10. Java 11, which was released in September 2018 is a Long Term Support (LTS) release with support until 2026. This is very similar to what many are used to from the Ubuntu release model (On a side note, they even planned to replace the version numbers with something involving the year and month of release or so, similar to what Canonical is doing with Ubuntu, but dropped that idea for some reason).
Using a non-LTS version of Java now implies a commitment to update your software that uses the JDK every 6 month. It shouldn't be as involved as migrating code from one major Java version to another in the past because, as described, the language changes are supposed to happen in a more incremental way, but it's definitely something to consider. If you don't want to make this commitment, you should stick to the LTS versions, which means to stick with Java 8 or Java 11.
For a new "greenfield" project, Java 11 is most probably the best choice by now. But it might be necessary to stick with Java 8 if the toolchain to be used does not fully support Java 11 yet.
Apparently in the future Oracle wants to release a LTS version every three years or every 6th release, so the next LTS release to be expected after Java 11 is Java 17 in September 2021.
Oracle transitioned to timeboxed releases. This means you will get a new Java release every 3 months, and a long term release every few years.
The Long Term Releases are expected to be supported for 3 years after the next release, so I wouldn't expect a new LTS release until some time late 2019 or early 2020, as December 2020 is the end of support for JDK 8.
I know that Oracle JDK 7 and 8 support hard float ABI on ARM Units. But I haven´t found any information about the OpenJDK 7 supporting this.
The clear implication of this page is that you can cross-compile OpenJDK 8 with Hard Float support. (See the example commands towards the end ...)
The page doesn't mention specific Java versions, so given that Oracle JDK 7 supports it it is likely that OpenJDK 7 will as well.
Cassandra 2.0.12 and Datastax Enterprise 4.6 both recommend using Oracle Java SE 7. However, public updates of Java SE 7 will cease in April 2015 meaning security updates and bug fixes will not be available without a support contract with Oracle.
My preferred option would be OpenJDK to avoid legal hassles with Oracle's click-through license (technically I can avoid the problem, but legally I cannot). However, it seems that OpenJDK is not recommended for 'reasons'. I can only see minor reasons why it doesn't work (using the string 'icedtea' in the version string) and no recent discussions, so I'm assuming it is not being tested and should be avoided.
Should I be doing new deployments with Oracle Java SE 8, OpenJDK 7, OpenJDK 8, or some other variant?
I would recommend using the version DataStax recommends if you can. While other JDK variants and versions will likely work, it would make sense to use what QA is actively testing with and others in the community are using. Cassandra even goes so far to warn you if you are using OpenJDK or a non-Oracle JVM (code).
You should be able to get away with using OpenJDK 7, but just beware that you may encounter various problems with heap, load, kernel errors, etc. With regards to Java8, Cassandra 2.0 won't compile on Java 8 (CASSANDRA-7028), but you should be able to run with it.