I have already read on documents saying that Hibernate version 5 is compatible with Java 11. but
Is Hibernate ORM version 4 also compatible with Java 11?
if not: What changes are required to upgrade?
Hibernate 4 is not compatible with Java 11 and was declared, for quite some years now, as ”end-of-life“, practically since end of 2015.
Full Java 11 support was announced with Hibernate version 5.4:
Hibernate ORM now supports JDK 11 out of the box.
Hibernate 5.3 lists Java 11 as supported in the latest release 5.3.22. Moreover, Hibernate 5.6 is also Java 11 compatible. This might be the last version in the javax namespace, yet it supports the transition to the new jakarta namespace.
Pointers on what changed or needs changes in your project are found via this question or in my answer to a similar question, related to migration from version 4.3 to version 5.2. Many things in that answer should guide you along the path.
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.
I have an application built in JDK 8 and Spring 4.x. I would like to move from Spring 4.x to Spring 5.x?
While going through this link "What's-New-in-Spring-Framework-5.x", it seems like Spring 5.x is mainly focusing on supporting JDK 8+ (9, 10, 11 etc.).
I understand that it is not saying anywhere that it will stop supporting JDK 8 related feature but just wanted to understand if it is completely fine to move to Spring 5.x while still being on JDK 8? Can someone please share their views here?
Spring 5.x requires JDK 8 or higher.
https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-5.x#upgrading-to-version-51
So you can migrate without any issues. In fact, I am using it with the same combination.
we are using a very old version of java installed previously in our server (version 1.4) and according to this case we used a very old version of iText2.1
Our main vendors planned to upgrade the server and they will upgrade the java version to 8.
Question: should i upgrade my application which uses the iText2.1, or it will work fine with the new Java ver.? and what version should i use then?
Note:i've tried to raise this question in the itext blog but they put the stackoverflow link for any technical question. , so please be kind and help me.
The above comment is really an answer:
I know that in recent versions of iText (I think 5.5.7 or 5.5.8) we made some small changes for Java 7 and Java 8. The minimum for iText 5.x.x is Java 5. Anything older than 5.0.0 is totally unsupported, sorry. iText 2.1.0 is from March 2008, that's 8 years ago.
Using Eclipse
I am Using 1.8_45 with iText5.7
No Exception and warning with it .
So Upgrade
and if you are not upgrade your iText2.1 with java 1.8_45
so it's give you Exception
yes you can easily upgrade your versions
1.8_45 to 66 jdk
with
iText5.7
I'm trying to integrate Drools into a Java 7 + Hibernate 3.0 project. Are Drools packages (most importantly JBPM) version 6.0 compatible with my current setup? My google-fu has failed me.
Thanks!
As of Drools 6.0, we moved from Hibernate 3.5 to Hibernate 4.2. Drools 6.0 is Java 6.0 compatible.
I looked up the Jira's, and it looks like persistence was added in 5.0 (See JBRULES-1761). 5.0 is thus probably your best chance -- but I suspect that 5.0 is probably Hibernate 3.3.x compatible (and not Hibernate 3.0.x compatible).
I highly recommend moving from Hibernate 3.0 to Hibernate 4.2.x or higher: for one, Hibernate 3.0 is based on JPA 1, which is an old standard. Most companies/organizations moved to JPA 2 when moving to Java 6+.
This question already has an answer here:
Migrating from java 1.4 ,EJB 1 to Java 6 and EJB 3 [closed]
(1 answer)
Closed 8 years ago.
I am working on very a old project ,the technologies used in that project are :
Java 1.4,
EJB 1.1
Weblogic 8.1
oracle 11g
I am thinking to migrate that project on oracle weblogic 12c with java 1.5 or java 1.6.
Can it be possible to migrate that project or not?
Could you please suggest me the possible steps I need to follow to acheive this.
It is definitely possible to migrate the project. However, you will be required to make code/configuration changes. You will need time to make these changes and to test that everything still works!
Rather than going Java 1.5 or Java 1.6, choose Java 1.7. According to this Weblogic version table, Weblogic 12c supports Java 1.7.
Migration pointers:
From Java 1.5 onwards, enum is a reserved word. If enum is used anywhere in the Java 1.4 source, you are going to get compile errors complaining about it. You will need to fix all of these errors.
Java 1.5 introduced generics, so use of any 1.4 classes that have been made generic in 1.5 will cause compiler warnings. For example: List stringList = new ArrayList(); will cause a compiler warning in Java 1.5 onwards, and should be re-written appropriately, ie: List<String> stringList = new ArrayList<String>(); Note: these are just warnings, so you don't need to fix them on day 1. It is advised that they get fixed over time though!
Update the XML schema references in all your Java EE XML files: web.xml, ejb-jar.xml, all JSPs, etc. What I mean here is that the schema versions that the project references are very old, you will need to update the schema versions to match the Weblogic 12c column in the version table. For example, Weblogic 12c supports EJB 3.1 so the root element in ejb-jar.xml should now be declared as follows: <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" version="3.1">. Do this for all Java EE XML files. After doing this, you'll may have some XML validations problems that you'll need to fix. Read the documentation and fix accordingly.
Update your IDE to refer to the appropriate versions of each Java EE specification, as defined in the versions table. Likely you'll get a bunch of errors that you'll need to fix. Fix them!
There will be more than what I've mentioned above. That said, don't be scared of doing the migration. Give yourself plenty of time (1 week for a small project, 4 weeks for a large project), and carefully start migrating. Remember to read the documentation!
Good luck! :)