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.
Related
I have a program in beta and I want to notice users when there is a new update avaible, so that they can have the best user experience. I thought about "asking" the server for the latest version and than look if its newer than the current one and notice him if his version is outdated. Any suggestions how to do it?
You have to use Java web start. From doc:
Provides an easy, one-click activation of applications
Guarantees that you are always running the latest version of the
application
Eliminates complicated installation or upgrade procedures
See more https://www.java.com/en/download/faq/java_webstart.xml and https://stackoverflow.com/tags/java-web-start/info
I've red in official documentation here, which says to use Hibernate validator 4.1.0.Final which is 5 years old.
I am not sure is old documentation or mistake?
What version should I use?
And If I should use proposed version, I would like to know why gwt dosen't support newer version?
GWT only supports Hibernate Validator 4.1.0.Final, for client-side validation. Server side can use whichever version you want (a priori).
The reason GWT doesn't support a newer version is that nobody ever invested enough time to update. GWT has dependencies on HV internals so it's not as easy as switching versions.
In the future, the GWT team would like to move validation out into a separate project that could either be picked up by the community and maintained, or die.
For now, unless you think you could step in as a maintainer, I wouldn't recommend using javax.validation on the client side.
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.
is there a way of having a language-mixed component framework like OSGi? I'd like to mix modules or bundles that are written in C and Java. On the site of NativeOSGi (https://github.com/abroekhuis/NativeOSGi) there is a hint, however the project seems to be not maintained anymore. Is there a way of getting Apache Celix and Felix to work together?
The easiest way of making Felix and Celix work together is through the OSGi Remote Services specification. Work is currently being done to make Amdatu Remote (an implementation of that specification) interoperate with Celix. I would encourage you to ask on the Celix mailing list, as they can probably tell you more about its current status.
Like Marcel said, the best way to go would be using Remote Services.
Since the Amdatu Remote Services has been working on a new release I am not sure if the current version is compatible with the Celix implementation. If this is not the case, we should work on getting it up and running again.
You mentioned NativeOSGi, and while the github page isn't maintained, we are still working on it (sadly a bit slow..). Basically the idea is to make Celix implement the NativeOSGi API (or base the NativeOSGi API on Celix, just a matter of perspective). Since Celix has had a 1.0 release, we have started working on the API, so expect to see some progress on the trunk wrt NativeOSGi.
I hope this helps a bit, if there are any other questions, feel free to ask!
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.