I am using Netty for a while now and could never solve this question. One can download four different versions. Three of them are actively getting developed.
3.x
4.0.x
4.1.x
5.x
As far as I understand 3.x is for JRE 1.5 and everything else for JREs greater than that. I am using 4.0.28 because it is the stable and recommended version. But what exactly is the difference or goal of the other versions?
I could not find any information about this on their website.
EDIT: I see close votes coming so I'd like to clarify: I'm not looking for someone who lists me all the differences in the code of the versions. But there has to be some sort of objective or purpose for the 4.1.x and 5.x versions.
3.x is deprecated. We maintain it because some users still use it widely.
4.0 is the current stable version. When in doubt, use this version.
4.1 is a backward compatible version of 4.0. It adds some cool new features like HTTP/2 and asynchronous DNS resolver. So, 4.1 is the version you might want to try when your application already runs on top of 4.0 and you wanna try the new features.
5.0 is a backward incompatible version. However, it's not like a rewrite we did for 4.0 vs 3.x. However, we did fix some API design flaws. You'll need to make some changes in your code to make your Netty 4 application run on Netty 5, but it's not like porting Netty 3 application to Netty 4 application. Eventually, 4.x will be deprecated and 5.0 will be a stable version.
It should be noticed that 5.0 had been revoked in Nov 2015, 4.1 is the newest stable version now.
If you want to know what are all new (and noteworthy changes) between these versions, you can visit these links:
3.x -> 4.0
4.0 -> 4.1
4.x -> 5.0
Related
I have a library which uses the Apache Commons Text library.
A test suite for my library runs fine in JRE. However, when I use the library in an Android app and try to run it on an old device (running Android 4.4.4 aka KitKat), it crashes with a NoClassDefFoundError. The offending call seems to be StringSubstitutor.replace().
What is the issue here?
As per the release history, Apache Commons Text requires Java 8 since version 1.4 (released in mid-2018), which is not fully supported on older Android versions.
Specifically, one of the missing classes is java.util.Base64, which was introduced with Java 8. On Android it requires API 26 (Android 8) or higher.
If you need to support Android back to version 7, going back to Apache Commons Text version 1.3 works, as long as you are not relying on any of the features introduced in later versions. (StringSubstitutor.replace() was already available back then.)
If you decide to go down that route, bear in mind that you will be stuck with a library that (as of January 2023) is almost five years old, to support an OS that is at least six years old and for which security updates were discontinued more than three years ago.
We have an application that uses Apache James 2.3.2, which is an older but stable version. We plan to migrate to the latest Apache James 3.4.0 and we have been going through the documentation for the same.
On this page, we see a note that says:
Apache James Server 3.4.0 represents the leading edge of development. This code stream has many more features than the 2.3 code, but is not be as well tested in production. Reasonable configuration compatibility has been retained with 2.3.2.
The above statement was a bit concerning, and we are unsure whether to migrate or stay on version 2.3.2.
What would be the recommended approach?
To answer my own question, I have learned that the recommended approach would be to upgrade to James 3.4.0.
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.
I would like to use the OpenNTF Domino API but to me it is not clear which version I can use?
The version of the extension library on the Domino server is 9.0.1.v00_00_20151122-0905 (upgrade pack 1).
If you're using Domino 9.0.1 Feature Pack 8, then 4.0.0 is the way to go. Otherwise, 3.2.1 is the right one.
The plan is for 3.2.x to get critical fixes (which is what 3.2.1 itself was over 3.2.0) but otherwise remain as-is, while future development will happen on the 4.x+ Java 8 path.
The version of ODA will depend primarily on the Domino server version. It sounds like you're running Domino 8.5.3 and we've not specifically developed against that version. There was a lot of new functionality added in 9.0, specifically around NoteCollections, which is spread throughout the API. I did compile a version some years ago for 8.5.3, but it was never heavily tested or officially released. The server in question was upgraded to 9.0 before the project went live, so I'm not sure if I even have that version any more.
Version 4.0.0 is the first specifically compiled for 9.0.1 FP8 and will not work on previous versions. That's because it includes the new core Domino APIs (encryption, ID Vault etc) added with FP8. It's not currently compiled for Java 8, but work on that has already begun in the develop branch.
Version 3.2.1 is the recommended version for 9.0.1 up to FP7. It will still work on FP8, but only if there is no intention of using the new Domino APIs added with FP8. It will work with the base Extension Library as long as the Graph API REST functionality isn't required (not a regular requirement at this time), for which ExtLib 9.0.1_v00_17 is required. That's because additional hooks were added to the core Domino REST service functionality in ExtLib.
For any general discussion about ODA, there is an OpenNTF Domino API channel in the OpenNTF Slack. The OpenNTF Slack team can be joined from the main OpenNTF website home page.
I have got an application which uses Java SE 5 and Hibernate 2.5. I have to upgrade / migrate it to Java 6 and a newer version of Hibernate. What is the best strategy?
Should I directly upgrade to the newest stable release (at the moment: 3.6), or does it make more sense to just upgrade to 3.0?
Is it a lot of effort to do such a migration?
I have no experience with Hibernate yet, but I already used Toplink JPA 1.0 in projects.
Can you give me some hints? Thank you...
Best regards,
Kai Wähner
Depends. If you'll use Java EE, then don't bother with Hibernate versions and focus on JPA 2.0. Hibernate will be just the implementation for the JPA. In case you really need some Hibernate specific feature, then check what's its version based on your AS implementation.
If you are not using Java EE, then I would go with Hibernate 3.6 if I'm planning to deploy my app in some months, or I would use 3.5 if I plan to deploy the app to production sometime next week.
The basic idea is: use the latest GA at the time you put something in production. This way, you ensure that you'll have a "supportable" version for a long time.
It's also worth mentioning that the Community versions are not always supported by the vendor. In this case, you won't get a support contract from Red Hat for Hibernate 3.5 or 3.6. If you need support, then you'll have to chose whatever versions they officially support.
I say go for the latest stable release as it will contain further improvements/bugfixes and give you more benefit overall. There have many changes since 2.5 so the migration will not be trivial, but later on, when you upgrade to subsequent versions, the migration steps will be smaller and easier.
Take a look at the migration guides to help you.
What is the best strategy?
It depends, if you have to maintain a lot of projects. Only do updates if you're working on a project. In other words it it isn't broken don't fix it. If you are still developing and you face problems in libraries then check more current versions which could have the bug already fixed.