Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am writing an eclipse plugin, compatible to java 1.5.
If anybody who is working with java 1.5 or lower or higher, installs this plugin, will it work well?
You should included a Bundle-RequiredExecutionEnvironment: J2SE-1.5 statement in your plugin MANIFEST.MF if you are targetting java 1.5. That is both documentation and a note to the OSGi runtime about what is valid within that bundle.
No. It won't work on lower versions if you are using java 1.5 specific library calls which are not available in lower versions.
It depends on what functions your plugin uses. Certain functions are eventually marked as deprecated and are dropped in future releases, this can cause issues when newer versions of Java will run your code.
On the other hand, new functions tend to be added from one version to the next, so in your case, older versions might crash since some functions your application uses simply do not exist.
At most, what you can do is to specify a minimum Java version, and eventually even this can cause problems.
Related
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 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 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 7 years ago.
Improve this question
So if I wrote an application for windows 8-10 on java, would it work for old versions like windows 98. And will it work correctly?
Both of them got the newest versions of JRE for example.
Well, you can't install Java 8 on systems older than Vista, so some programs might not run (specifically ones that use Java 8 features and APIs). Otherwise, they would work the same way, unless you do some sort of hacks that may break things.
If you had done your project in oldest version of java supported in vista/xp/windows 7 systems your application works perfectly it only depends on java environment once if it is satisfied your application will run without any compactability issues.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Should I always use the latest JRE version of Java 7 for a ubuntu production server ? Or should I be careful while upgrading between these minor versions too ?
Does the same rule apply to while making a choice between minor versions of Tomcat7 server?
I'm asking this in context of making a choice only amongst the minor versions of Java 7. Also please mind I'm asking this for a PRODUCTION server so I need extra carefulness.
This is a security issue; the minors are almost always security updates. Use the latest of whichever JRE (Oracle, OpenJDK) you choose.
I would suggest you to use the latest one, but at the same time, i would suggest to move your updates first on a stage server , test them thoroughly be fore moving to production. This is because, many time the project code uses library/jars who are compatible only with certain version of JRE, and upgrading JRE version might break them. So, either you need to update those library /jar as well or you live with current JRE version.
If those jars are not being maintained, you may be out of luck.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have class corresponding with Java 1.5 and later. It's compiled in Java 1.7.
And now turns out that I have to launch it on Java 1.3.
How to solve that problem?
if you have the source files iwould just try to compile it in the version you need. if this won't work you need to "get rid of" unsupported stuff (e.g. generics)
if you don't have the source-files, i would trying to decompile it and compile it in the version you need.
Stackoverflow Answer on decompiling
You code in 1.5 and you compiled in Java 1.7(Java 7). if you want to run this one in to Java 1.3 then you need to sure about API what you used in code. The API what is used in code it should support in Java 1.3.
Example:-
Lets have a example. if you use generics in you code. but as we know java 1.3 not support generics. so this code not going to work on Java 1.3. you need to remove and look for alternative.
There are a few things to consider:
Class format (you can set the target class format to 1.3 even with 1.7 compiler)
API changes
Must not use generics
Ok, I solved it that way (quite primitive):
I compiled it using javac, then I opened it in Hex Editor, eight byte changed on 2F, saved and it works!