The problem
I'm experimenting with Akka's cluster support. I got stuck with ClusterSingleton support which appears to require JDK8... Which I can't use.
As per documentation here I need to include the following library:
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-cluster-tools_2.11</artifactId>
<version>2.4-SNAPSHOT</version>
</dependency>
As it appears in my tests, the entire akka-*2.11, (compiled with Scala 2.11) requires JDK8, including akka-cluster-tools. I'm not a Scala guy, but it seems quite strange - Scala 2.11.1 release notes suggest, that JDK7 is more than enough:
The Scala 2.11.x series targets Java 6, with (evolving) experimental support for Java 8
Options
What are my options? I see the following:
Drop the idea of using Akka since new releases will require JDK8 as it seems. JDK8 is sadly not an option
Hope there would be akka-cluster-tools_2.10 and my problems disappear. Will there be akka-cluster-tools_2.10?
Forget about akka-cluster-tools_2.10 and use akka-contrib_2.10 instead.
There's a chance it would work, although
It's going to be more difficult, as the current documentation refers to akka-cluster-tools
I'm just starting with Akka and already need to use deprecated libraries...
Thanks
f
As Ryan said in the comment, Akka 2.4 (which isn't yet) requires/will require Java 8.
You can still use ClusterSingleton, Sharding, DistributedPubSub in Akka 2.3 just that it is in the akka-contrib package. And you can find the docs for it under http://doc.akka.io/docs/akka/2.3.12/contrib/index.html so no problems with that.
Additionally the differences in the API:s between 2.3 and 2.4 for the cluster stuff isn't very huge, so it is very much possible to make that move in the future without being too big an effort.
The back side of it might be that improvements to the cluster tools in 2.4 might not necessarily be back ported to 2.3 and that the main development effort will be focused on 2.4 in the future.
Related
Why is it that I can't keep the latest version of Java, that I have to downgrade to Java 8 for almost all Apache Projects?
Is Java not backward compatible?
A program compiled to ByteCode on a older JDK should be run perfectly well on the JVM of a newer JDK.
Why is it that I have to go through the pains of building from source?
I thought this was one of the things that Java was supposed to overcome!
This problem is not exclusive to Apache projects. With the newer Java Versions it's not so much about 'understanding the older code' but more about 'am I allowed to use these features the old way' (modularization).
In some cases the older code also uses features that are just not part of the latest JDK any more (e.g. removal of JEE Modules). I'd recommend to read Oracles Migation Guide for more on this topic.
For (bigger) projects the Migration to >Java8 is something that needs to be planned and organized and takes a lot of time.
I'm working in a company that has many projects in Java 8. Those projects are valued as old, and our team would like to upgrade the version. However, we need valid points in order to unlock the situation.
Those projects are using Spring and Hibernate (if it's ever useful).
What factual points could we give to our company to upgrade the versions, if any factual points there is ?
Examples of useful, valid points would be:
Security improvements
Performances improvements
New libraries or framework updates which could ease the development process
New possibilites/features with an upgraded Java Version
...
Possibly, backed up with documentation or links to useful resources.
old Java version will eventually stop getting new security fixes, which will make your software more vulnerable
using an old software stack will make it harder to find new developers willing to work on your software. Java 8 probably isn't too old for that yet, but in a few years that will be similar to finding "Java 1.4 developers" right now.
using an old software stack can severely limit your selection of useful third-party libraries and/or tools. A given library that you really need might require a more recent Java version or (possibly even worse) a library that you already use increases it's Java version requirement with a new major release (leaving you stuck with an old Java version and an old software version that might be missing important bug fixes).
There are several advantages from switching to newer Java versions, which are probably not the main reason to switch, but could be considered additional incentives:
newer JDK implementations might have better optimizations (in JIT and Garbage Collection mostly) that might help you get better performance from existing hardware (or reduce your cloud computing costs)
newer Java versions tend to have support for more modern technology, like the newest TLS versions and cryptographic algorithms which can help you data more secure, if you use them correctly.
new language features might improve your code style, which makes your developers happier, which means less churn which saves money on hiring new developers.
The reason to jump from 8 to 11 is the support of Oracle (or other implementation).
You can find the roadmap of Oracle here. For Java8 you are safe up to March 2022 for the premier support and extended support to December 2030. For Amazon Corretto they will provide free support and updates for version 8 to (at least) June 2026.
So the major reason to update your JVM version is support and updates. You still have time to update your version but you also have to wait for you 3rd party library to deliver compatibility with Java 11.
If you wonder why from 8 to 11 and not to 9 or 10, the reason is that 9 and 10 are not marked as LTS (Long Time Support) meaning that the different implementation won't provide any support and updates (or not for long) for those version when the next one is release.
Security updates for Oracle Java 8 are only provided via enterprise licenses and you could save that amount by using newer stable releases.
Apart from that, using newer versions also guarantee better integration with modern JVM tools, like up-to-date build tools.
I have a Java application using Grizzly 1.9.59, Apparently around the version 1.5.x version 2.0 was also released with a totally new and incompatible API. Both versions are being developed 1.x being legacy.
So taking in consideration that both versions are being developed is it safe to assume they offer the same capabilities? What would be a really good reason to upgrade to 2.3.15(latest)?
Is there any documentation comparing both versions feature wise?
Does anyone know if they plan to stop developing 1.x, if so when?
I can't answer the question fully. But from their website:
The latest stable release of Grizzly is 2.3.14. Older versions of Grizzly (2.2.x, 1.9.x, 1.0.x) are still available and can be found on Maven Central.
So they see 1.9.x as an old version and on their website there are no direct download links, to 1.9.x. To me at least this indicates a wish to make uses adapt to the newest version.
So taking in consideration that both versions are being developed is it safe to assume they offer the same capabilities?
NO! It is not, many libraries run a legacy version, which primarily receives bug fixes and minor updates. File the new fancy version receives the awesome updates.
What would be a really good reason to upgrade to 2.3.15(latest)?
At some point when 1.x.x no longer is developed you will have to do it anyways. But really it is a cost/benefit situation you are in
How much time will it take to do
Will you continued to use Grizzly
Is the new API, so hard to learn?
How much do I need to change the rest of my code
and so on, personally I would make the jump, if I where looking for a long term solution.
Is there any documentation comparing both versions feature wise?
I have not been able to find any, not even on there Jira
Does anyone know if they plan to stop developing 1.x, if so when?
Try their mailing list for answers to that, they properly no more and might be able to provide a feature table as well.
Summary:
Their website focus on the newest version (and refer to prior as old versions), though 1.9.x still is in development. You can not be certain the two different versions has the same features and capabilities. If they stop developing 1.x.x you would still need to update to the newest version.
For questions about more project specific things try their mailing list
A small note, your question is pretty open. I know my answer is more a comment but not enough space in the comments.
As I'm sitting here modifying PircBot, I've just noticed that the entire backend was written to support Java 1.1. It has a custom queue implementation, uses hash tables, custom producer/consumer implementations based on wait() and notify() signaling, etc. Even Commons-lang lacks any support for things that Java 5 brings to the table like generics. You can pull a bunch of other examples of very popular frameworks that try as hard as they can to support 1.1.
My question is why? Why are certain parts of the Java community refusing to support new versions? I go by this theory: Old versions use older versions of frameworks and older JVMs, newer versions use upgraded frameworks and JVMs. You upgrade everything with the software.
Now I can partially understand people still running Java 1.5, but 1.1? If your running anything before that then your obviously not upgrading the JVM because of stupid policies/scared of the unkown, and therefor aren't going to upgrade to newer versions of software. So why are we still supporting them?
On a related note, if you are writing a new framework should you support anything <1.5? Should you try forking existing frameworks, upgrading it to 1.5, then talk to the maintainers about using it?
Much more specific discussions (this is about support in general):
Is there still a good reason to support JDK 1.4?
Dropping support for JRE 1.3
Because its easy! From Java 1.1 to Java 1.4 just tiny language features were introduced (strictfp for example). So why restrict yourself if you don't need to. So lets say you write a StringUtil class or you parse Word files then is simply does't matter. Just starting with Java 5 you have language improvement and from Java 1.0 to Java 1.1 of course inner classes.
This is just for the language and not so much for the libraries. There are interesting additions of course.
I think the most common reason is, that new features introduced in later versions are not used anyway. I mean, if a library does not use new features like generics or advanced concurrency features, there is no compatibility overhead at all.
Backward compatability?
Changing the level of JVM support, should warrant a major release. I.e. version 1.x goes to 2.x to indicate this.
Also I believe to have read that to get most coverage in mobile phones, you need to target 1.1. That may be old though.
I know of at least one commercial enterprise that decided they would never move beyond 1.1 so that they could run forever on both java JVMS and .NET with the same source code.
A list of potential compatibility problems is provided by Sun: http://java.sun.com/j2se/1.5.0/compatibility.html.
Have you encountered other problems when running/testing old-1.4-applications against Java 5 (e.g. A specific library no longer working ....)?
The Java 1.5.0 deprecated list may be of help.
You may discover an alternative list of backward compatibility problems in all versions of JDK including 1.4 and 1.5 at the following web-sites:
JDK-Results at Japitools Home Page:
In an ideal world each JDK version would be perfectly backward compatible with the one before. As the following table shows, in reality this is not the case ...
Test results for JDK at Java Upstream Tracker:
This service is aimed at monitoring and analyzing Java libraries development. It is looking for new releases of various libraries and checking them for backward binary and source compatibility ...
These results were obtained by static analysis tools and can be used together with the official compatibility notes (Incompatibilities in J2SE 5.0 since 1.4.2 from Sun/Oracle).
In general, code that runs under 1.4 should work under 1.5. I don't think any previously deprecated methods were even removed. However, bugs are fixed between releases and you might get some slightly different behavior if your application was written in such a way that depended on the bug (I have encountered this with a Swing application).