Attempting to move over an older web app from Java 6 to Java 7, if the application and container stay the same, can some EhCache cluster nodes be on JDK 7 (or 8) and other remain on JDK 6 without any compatibility issues?
You should not have any problem with this. Serialization is stable across JVM versions.
Related
At the moment, we have both our Hadoop cluster (CDH 4.1.2) and services that communicate with it via hadoop-client running Java 6. We're planning to move those client components to Java 8 leaving Hadoop servers running on top of Java 6 as they do now because Cloudera has declared support for JDK 8 only since version 5.3.0, and we're not planning to upgrade Hadoop - details here:
https://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cdh_rn_new_in_530.html
Therefore, our concern is whether different versions of Java in cluster (6) and in client components (8) may lead to problems of any kind. Internet hasn't been of big help as long as Hadoop compatibility with Java is mainly discussed regarding migration of server components, so please share your experience relevant to this matter if you have one.
Since the release of Java 8, I found myself slowly becoming dependent on Java 8-specific features (ex. lambda statements) on a library project that I have just started.
I have seen many other projects which, to this day, still build against Java 7, or even Java 6, causing me to second-guess myself.
Is it a good idea to immediately start building against the newest version of Java, or should I still use older versions?
Note that unlike those other projects that have started back when Java 6/7 was the newest version, mine was started recently when Java 8 is the newest.
There are two reasons I can think of that would require staying with a pre-Java 8 JVM:
You are writing a library that is being used by a large group of people outside your organization who are still stuck on a pre-Java 8 JVM. If you use the latest and greatest JVM, they won't be able to use your product anymore.
You are dependent on a 3rd party library that has not upgraded to Java 8 and breaks on Java 8.
Since you mentioned this is a new project, #1 is unlikely. Even if you plan on having external users, if it's a new project, requiring the latest version of the JVM isn't really an issue.
Number 2 is also getting more and more unlikely as the more popular 3rd party libraries have released updates to work on Java 8. Even the few stragglers are usually OK working on Java 8. For example I use an ancient version of hibernate with Java 8. I just don't use any Java 8 features in any mapped fields/entities.
Java 8 denotes a major change to the language since Java 5 (or perhaps its inception). If you are targeting specifically the changed language parts (which I guess you claim) then making it usable only by Java 8+ runtime makes sense.
When Java 5 occurred 10 years ago and you wanted to use all the new features introduced at the time (e.g. foreach statement, Enums etc.) into your own library development, what would you have done? I believe you would have made your library require Java 5 at the minimum. If you agree with that, then that (sound) logic applies consistently to your present situation as well.
For server side application, possibly a version or two prior to the current version as suggested by EJP.
On the client side however, I don't see any point in trying to support older Java versions. The JRE has been auto-updating since at least Java 6. It has gotten to the point where Java Web Start launched applications cannot specify an earlier than current JRE. Or rather, it can specify any JRE it chooses in the launch file, but that will be ignored in favor of the latest version installed on the user's computer.
On the GlassFish homepage it is stated that
Java EE 7 requires JDK 7 or above, JDK 8 u20 or above is recommended for GlassFish 4.1.
So I am wondering, why it is recommended to use it under the JDK 8, as GlassFish 4.1 is a Java EE 7 application server?
Is it just because that I will be able to use the new Java 8 functionalities? Or are there deeper reasons for this like stability, know bugs etc.
So does the GlassFish really runs better on the JDK 8 than on the JDK 7, or may I ignore this statement and just install it under JDK 7, if I do not use the new functionalities provided under Java SE 8?
So I am wondering, why it is recommended to use it under the JDK 8, as
GlassFish 4.1 is a Java EE 7 application server?
I guess they just recommend to use the newest compatible non-beta Java version which in this case is Java 8. The Java EE specs version (in this case Java EE 7) which is implemented by Glassfish 4 and the JDK version which is required (or which can be used) to run the server are two different things.
Also note that Java 7 has its EOL (End of Life) in April, 2015. There will be no further updates for Java 7 so at some point you'll have to switch to Java 8 anyway.
Is it just because that I will be able to use the new Java 8
functionalities?
This could be one reason for you to use JDK 8.
Or are there deeper reasons for this like stability, know bugs etc.
I guess there may be some bugs in JDK 7 which are fixed or do not occur in JDK 8, but this shouldn't be anything critical. In terms of stability I think the values are similar when not the same.
So does the GlassFish really runs better on the JDK 8 than on the JDK
7, or may I ignore this statement and just install it under JDK 7, if
I do not use the new functionalities provided under Java SE 8?
I wouldn't say that Glassfish runs better, but I would also recommend to use the latest compatible Java version. But you can currently also safely ignore the statement and use JDK 7.
For some additional information, this spring.io blog post contains a nice summary about Java 8 in enterprise projects and with various application servers.
One reason that was understood for GF to recommend using Java 8 is to leverage on new functionality it offers, such as SNI support for example. However, GF itself is not yet making full use of it.
I am using Jboss 2.4.11, if i upgrade JDK from 1.4 to 6 How is the jboss server going to handle the application?. What are the common things i should start investigating while i am in the process of the upgrade. I am looking at the Oracle's documentation and other posts in stackoverflow related to jdk 6 backwards compatibility with v1.4. My question is more specific towards using Jboss server. Also the application uses ejb 1.1
I'd recomment to move from one consistent system to another one. Even JBoss 4 needs a special version for JDK1.6. Java 5 brought MBeans rigth into the VM and older versions of JBoss used MBeans for configuration. As there must not be to MBean servers within a single VM this was a big issue, when migrated to java5. As EJB 1.1 is still supported I'd recomment to move at least to JBoss 4.2 as this is still kind of similar to older versions, while JBoss 7 is totally different.
The only thing that will really help you to get the migration a little bit smother are tests. At least quite a number of integration tests.
I just need clarifications related to JBoss Application Server. I've developed a project which is compiled in Java 6. And it is deployed in Jboss 5 version. Till now I didn't find any problem with the application. But I want to know will there be any possibility that Jboss will have any backward compatibility problem. Or does Jboss needed upgradation with respect to Java version. Any suggestion would be appreciable.
Thanks,
Marshal.
Even if JBoss 5 is compiled with Java 5 there shouldn't be compatibility problems at a language level.
As for the libraries there might be a problem but those that JBoss requires should have been taken care of. This leaves you with core libraries that JBoss might have replaced in its class loader hiearchy and thus might have an older version. In that case you could put those libraries into your application and effectively override the JBoss versions on a per-application basis. We did that with some XML libs (IIRC JAXB was one of them).
As an alternative - as suggested by #Geziefer - use a JBoss 5 version specifically compiled for Java 6.