Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
i would like to update from Oracle Java to Adopt OpenJDK.
Therefore i have some question before i start doing the update:
Some information about the application i use:
2 applications
Application 1 uses Java 8
Application 2 uses Java 11
My Questions:
Are there any known problems updating from oracle Java 8 to AdoptOpenJDK 8?
Are there any known problems updating from oracle Java 11 to Adopt OpenJDK 11?
Is it even possible to run a Java 8 Application on Java 11? (Can i use Adopt OpenJDK 11 for both applications?)
Is there any guideline to update from Oracle to Adopt? (Or just straigt forward?)
best regards
For a given Java version (since Java 8), the various commercially-supported OpenJDK builds are almost drop-in replacements for the Oracle JDK.
If you're writing an application with a GUI, you'll find some differences in the fonts, and in colour profiles. The Oracle JDKs also have better support for Java Flight Recorder (if anybody uses that). There's little support in OpenJDK for the ancient Java Web Start, but there are alternatives.
In my experience (which is nearly all in middleware), choice of JDK (for a given version) is almost always a decision about support, and rarely about features. I've rarely encountered any technical problems moving from Oracle JDK to OpenJDK, or vice versa.
I've also not found any problems running Java 8 applications with Java 11 and later. However, Java 11 decoupled several components -- again most related to GUI applications -- into separate JARs.
But, in the end, this is all a matter of testing, isn't it? If your testing is sufficiently thorough, any problems with compatibility will be flushed out. I certainly wouldn't rely on anybody else's claims of backward compatibility without thorough testing.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am trying to get my head around the personal and commercial usages of oracle jdk vs open jdk and need validation and inputs on my understanding.
OpenJDK: Free for personal and commercial use.
Oracle JDK: Free for personal, paid for commercial.
From an organization's perspective, it will be cost-sensible to go for a free version using open jdk rather than shell out money on licenses. So why ever opt for an oracle jdk? What's the trick here?
One possibility I can think of is support. Open JDK has no long term support, has a new version release every 6 months, so if my application is running on Open JDK 8, after 6 months with the new jdk being made available, there are chances of my application to stop working?
If yes, that leaves me with the following options.
I would need to either migrate to the newer open JDK version.
Had I been using oracle JDK all along I had the guarantee from Oracle that my app still works even after whatever new releases.
Since up-time of products is crucial to the organization, folks don't mind shelling out on oracle jdk licenses than landing up in a situation where you saved bucks but on one fine day your processes stop working.
Is my understanding correct, and if not what all am I missing?
Yet another perspective I have in mind is how is the release of new open jdk version going to stop my applications from working, my app is still running on previous version of openjdk which is perfectly compatible - but yes I might not be able to leverage the new features released in the jdk if I do not migrate.
Thoughts?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
We want to migrate all our production services to Java 10 from Java 8. As I understood, we might face issues with builds (gradle etc.), dependencies etc. for development. But when it comes just to the JVM itself, i.e. running services, will we face any issues if we just install JVM 10 in production to run our jar services?
I'm not sure why this has been downvoted since it seems a reasonable question.
Oracle's own guidance for moving applications from JDK 8 and earlier to JDK 9 and later is "applications that just use java.se should just work". If you have not used (directly or indirectly via a third-party library or framework) any JDK internal APIs (sun.misc.Unsafe is the most infamous) then you can leave all your application code on the classpath and this will most likely work without change. There are a few differences that might catch you out with changes to things like command line flags.
I've written two blogs on this, which might be helpful to you:
https://www.azul.com/jdk-9-pitfalls-for-the-unwary/
https://www.azul.com/jdk-10-pitfalls-for-the-unwary/
You should also bear in mind that it doesn't make any sense to migrate to JDK 10. JDK 11 will be released next month and, at that point, updates for JDK 10 will stop. It would be better to migrate to JDK 11. If you're looking for long-term support Oracle is now charging for this. Check out our Zulu OpenJDK builds.
A good starting point is the JDK Migration Guides on the Oracle download site. The JDK 10 Migration Guide covers migration from JDK 8 to JDK 10 and can be found here:
https://docs.oracle.com/javase/10/migrate/toc.htm
Another good resource is the JDK release notes as these include notes on the known source, binary and behavioural compatibility issues. You can find the release notes for the JDK 9 and JDK 10 releases linked from here:
https://www.oracle.com/technetwork/java/javase/jdk-relnotes-index-2162236.html
Another resource is the videos from conferences. I've prepared several times on the topic of migrating to JDK 9 and beyond. A recent one from Devoxx BE 2017 can be found here:
https://www.youtube.com/watch?v=uSR5JroBp34
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
The target environments of my code use older Java versions (Java 7, Java 8). I use JDK 7 for development.
Will there be advantages if I use the most up-to-date JDK for my development, which is JDK 9 (and specify source=1.7 and target=1.7)?
I am aware that my code must not use any API which is not availabke on the target platform.
For the can I? Yes. Since backwards compatibility is important in Java, there's no technical reason why you couldn't do it. Sometimes company policies mandate a specific JDK version for development though.
In general the main advantage of using a later version of the JDK than what you're developing for is getting familiar with the later version. This may also increase your interest to migrate the software itself to a later version, if you notice it to be useful: for example you notice you love lambdas, so you migrate from Java 7 to Java 8.
Since the resulting bytecode is the same (not that it really matters) and the tools you use usually don't depend on the JDK, it has very little other effect. You can (usually) run code safely on newer JREs, so there's no difference with that either.
For the should I?
Whether you should start using JDK 9 now is primarily a matter of opinion. As Oleg pointed out it's not actively pushed everywhere, so at least you're not late and have time to consider moving forward for a while still (maybe toy around with it first before considering it for work use). Due to the large architectural differences between Java 8 and Java 9, I'd expect there to be a lot bigger gap in acceptance than between older versions.
However it's not all gloomy. There's a pretty good wrap-up of the features here and even if you are sticking to Java 7/8 projects for the time being, I see no reason not to do that on JDK 9 when you feel you're ready to have a look at it (and there is no hurry). I haven't installed it yet, although I've read about the decisions (good choice they didn't remove Unsafe).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have some big projects running on Java 6. But I plan to start building them in Java 8 since a lot of build tools have moved away from Java 6.
Is it safe for me to simply compile them with Java 8 and then deploy them in a web container running Java 8? If not, what are the considerations?
FYI, they don't have a proper automated test suite in place.
The problems can be related to:
deprecated methods that are removed in java 8 and you used in the old java 6 code
different behaviour for some methods:
There are aspects of the platform's behavior that are intentionally unspecified and the underlying implementation may change in a platform release.
configuration of web container that can be different from a version supporting java 6 and the version supporting java 8
external libraries that changed during the passage from java 6 to java 8 removing old methods so that your code can't compile
So yes it is possible that the passage from java 6 to java 8 can broke your code.
But if the code compile it is quite sure that the behaviour of the code is the same, because generally (but not always) a retro compatibility is granted. You can be sure of that only running a complete set of unit tests both on java 6 and java 8 versions.
Here some example of not compatibility between java 6 and java 7:
JDK-6527962 : Retire the non-standard package com.sun.image.codec.jpeg. If your code use this package the it doesn't compile on java 8
JDK-6563734 : Path2D.Float and Path2D.Double should have final getPathIterator methods If your code ovewrite the methods declared final the code will not compile passing to java 8
Here a complete official list of incompatibilities between java 6 and java 7
Here a complete official list of incompatibilities between java 7 and java 8
It usually should be, since most of the features are backward compatible. However, there are no guarantees. Please do follow the proper process and do testing before rolling out to production.
For web container , with jdk, version would also have changed. This may cause some problems depending upon the software vendor and what all services you are using from the container ( JNDI, connection pooling etc).I once had a problem in migrating application to higher version of JDK. We also upgraded Websphere. We were using JSF, and higher version of WAS had JSF jars included, which was clashing with our application jars.
Your apps may be using a lot of 3rd party library which may be impacted. Again, mostly you should be Ok, but there can be small issues. Without knowing your applications, I can only suggest migrate and test to confirm.
You need to test things very thoroughly. If there are bugs, then it is imperative to find them and fix them before you move on to the next version. If you have a sunny day scenario and do not have bugs coming from the upgrade, then at least you know that for sure after the testing.
However, you need to know what to focus on. You need to read about changes applied on version 7 and on version 8.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Java 6 is a stable version of this programming language. But I would like to upgrade to the current version java 7. At this time, is recommended to use java 7 in production? Where I can find updated information about the possible problems that I can get if I upgrade to java 7?
Why use or not use java 7 to make JAVA EE applications
This was added later. The main reason not to use Java 7 is that your web server might not support Java 7. e.g. some very expensive EE servers haven't got round to migrating to Java 7 in the 2.5 years since it was available for testing. IMHO this is pretty poor given the money they charge.
At this time, is recommended to use java 7 in production?
AFAIK, Java 7 is more recommended than Java 6, give it is not supported for free any more.
Java 7 is a requirement for the G1 collector, Java Mission Control and JavaFX 2.
Note: with Java 8 coming out soon with many new/powerful features, I expect many developers will be using it by the middle of 2014.
Where I can find updated information about the possible problems that I can get if I upgrade to java 7?
Most of the problems have been around client applet security.
https://blogs.oracle.com/henrik/entry/migrating_from_java_se_6
http://docs.oracle.com/javase/7/docs/webnotes/adoptionGuide/
http://www.slideshare.net/myfear/practical-migration-to-java-7
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp?topic=/com.ibm.iea.was_v7/was/7.0/Architecture/WASv7_JavaCompatibility/player.html (note this has audio)
You should use a supported Java version. Have a look at the Oracle Java SE Support Roadmap. Java 6 has reached "END OF PUBLIC UPDATES" - so it is not supported anymore.
At least you should run your Java 6 code on a Java 7 VM.
Aside from the convenient improvements to the language in 7 and the fact that 6 is no longer supported, there were some very serious security issues with 1.6 that caused Apple (amongst others) to drop default support for Java.
Those issues were fixed with 1.7 and for that reason alone, you should update.
Two blogs detailing the controversy below;
http://www.intego.com/mac-security-blog/apple-drops-java-in-latest-os-x-security-release/
http://www.darkreading.com/vulnerability/apple-removes-default-java-support-in-br/240009305
it is dependent, if you are going to make an application for android you may use Java 6, but if your creating a application for desktop it is recommended to use Java 7.
Java 7 have some improvement of course, specially on file io, which is .nio package.