I want to change the JDK version 1.5.15 to 1.6.29. If I do this, will any problems occur in an existing application that was developed under JDK 1.5.15?
Technically that shouldn't be a problem. But I would have a bad feeling doing this without enough test coverage. There was a project in my company were they were also changing to a newer java version (don't remember which one). Everything seems to be fine but after some time a few bugs were rising. It turned out that one developer illegally relied on the order of a Collection class. The bug was caused by a changed implementation.
Take a look at the Java SE 6 Compatibility with J2SE 5.0 document. It should be ok, but please go through the incompatibilities section just in case.
Try to compile your code with new JDK(1.6.9) classpath than you are fine no need to change anything.
If code change require follow some online JDK 1.5 to 1.6 migration tutorials already available.
You will have to test this. It probably is possible to compile and run your application with JDK1.6, but some behavior might have changed in a subtle way. An example of such a change between JDK1.6 and JDK1.7 I recently encountered is posted here on StackOverflow. Although the project compiled just fine, testing (unit tests, integration tests and manual testing) revealed some issues which weren't caught by the compiler
No i don't think it will create any Problem.
Related
Disclamer
Sorry in advance if this is a stupid question, but my research to clarify this was not as successful as i needed it to be.
Problem description
I am working on a project using jdk 11 and in order get decent testcoverage, i added something to mock calls/answers to/from external services. So i included wiremock.
As suggested on their setup getting-started section, i included
testImplementation "com.github.tomakehurst:wiremock-jre8:2.34.0"
Even though everything works on my machine (and tests run fine on the pipeline), i don't know if this will potentially cause issues on other machines. The architect involved in the project also stated his concern that we do only use jre 11.
Therefore i need some more insight to either change things up or argue why this is not an issue.
Attempts so far
I expected there to be an higher version of wiremock on mavencentral, but ther were only two projects:
mvnrepository: wiremock - last updated Sep, 2020
mvnrepository: wiremock-jre8 - last updated Sep, 2022
To my surprise, wiremock-jre8 was the most recent version. I don't know what the older version was compiled with but i was using annotations that wouldn't work with the 2020 version either way. So it would be nice to not downgrade the current implementation to a less readable solution.
I should mention, that i only guess that wiremock-jre8 has been compiled with jdk8 from the naming. I did not find any evidence about what compiler did produce the bytecode for either of those dependencies or clues on how to interpret this.
When trying to figure out how back and forwards combability works with java, the compiler and the produced bytecode, i found this older post. In short it states:
Compatibility from the point of view of javac (as it is the part specific to the JDK), meaning that the bytecode generated can be run in future releases of the jvm (that is more related to the JRE, but also bundled in the JDK).
JDK's are (usually) forward compatible.
JRE's are (usually) backward compatible.
I do understand that in parts, but not fully concerning my issue. Especially the "usually" part.
So are there some more insights someone has to spare to enlighten me? :)
The Download and Installation section of their documentation contains this sentence:
Additionally, versions of these JARs are distributed for both Java 7 and Java 8+.
So if you are still running Java 1.7 you must use the version for Java 7.
For all later versions of Java there is the version for Java 8+ (the version that you use.)
Since this is an actively supported project any problems related to Java versions later than Java 8 will be properly addressed and resolved (see for example Build on & fully support JDK 17 which was resolved in "com.github.tomakehurst:wiremock-jre8:2.32.0").
We have an old project using gwt 2.6 and therefore we need to compile with -source 1.7 option.
The JRE and JDK used are 1.8, but compile with 1.7 source code option.
We want to use the new compute function from ConcurrentHashMap which is only available from java 8. When using eclipse and maven everything compiled well. On the other hand IntelliJ is complaining. My question is, will it work or will we have issues with it?
Will this project run?
Searching in google for ConcurrentHashmap compute, java 8 and source code level 1.7 did not give any info.
If at all, this would require a lot of careful "manual" work.
When you look at this question for example, you can find that there are various different ideas how people want to enable "stream based" functional programming with Java 7. Maybe, after doing a lot of research, you might be able to find similar things regarding such "enhanced collection" features.
But then, all of that might be quite fragile. The fact that some examples might work fine wouldn't mean that you would be able to run a large production code base on a Java 7 VM.
Thus more of a non-answer here: be careful how to invest your time and energy. Instead of trying to backport libraries to Java 7, rather look into moving your whole project onto Java8 at least. Especially keeping in mind that the release cadence for Java has changed significantly, and going with outdated Java versions for many years is simply even less desirable compared to a few years ago.
Well, the simple answer is that it will not work. The target runtime will not have the updated API (i.e., the compute*** methods won't be on the version of Map that Java 7 has).
So if you deploy that code, the runtime will understand the class version, but will raise NoSuchMethodError and similar errors.
In addition to this, there are many reasons for upgrading your runtime.
What is the best way to migrate Java code of an older jdk (1.5) to a more recent Java version (1.8) to provide from its new features and improvements.
We have a large Java jdk 5 code base and want to migrate to jdk 8.
There are a lot of compiler warnings and hints (e.g. diamond operator, multicatch, unnecessary (un)boxing, etc) which will improve the performance, code readability, etc.
We are using Netbeans IDE. Are there any plugins which we can use or are there migration scripts?
The likelihood of your code being incompatible with Java 8 is slim, since Java has taken great strides to ensure backwards compatibility with all previous versions.
The issues that you'll likely run into lie much deeper, likely in implementations of collections or methods who have changed over the years.
If you don't have a test suite that covers the critical paths of your code, start there. You'll need that test suite to ensure that the migration hasn't horribly broken anything.
Next, peruse the compatibility guides for Java 1.7 and Java 1.8 and be sure that nothing that you're using in particular is impacted by those changes.
Lastly, the code cleanup piece can be tackled, but it shouldn't be addressed right now. The only thing you need to concern yourself with is to get the platform running on the new version of Java. As you work in the code base, discipline yourself and the team to use the newer Java idioms, such as the diamond notation, and try-with-resources where applicable.
Unfortunately, there are no magical ways to achieve what you are asking, but here are a few pointers that can make it easier for you to migrate the code to JDK 1.7 (note that JDK 1.8 has been out for some time now, and 1.7 is already out of support officially by Oracle):
Use checkstyle or a similar plugin in Eclipse to find the problems
Build your project with JDK compiler level 1.7 in Eclipse; warnings given by Eclipse are much more user friendly than the warnings printed on console by command line compiler
In theory, JDK 1.7 is backwards compatible with 1.5. The only exceptions are assert and enum keywords. If you used these words as user defined type/method names, you'll get a compilation error. So for most part, you can get right down to warnings. If push comes to shove, you can choose to ignore many of these warnings (of course, only if you must)
Found what I was looking for: Netbeans offers Inspect and Transform.
This can be used to transform your complete code base (or parts of it) with a configuration of changes.
This is how it works:
select your project
click Refactor menu
click Inspect and Transform menu item
select configuration and configure it using the Manage button
choose your desired transformations (e.g. Can Use Diamond, Join catch sections using multicatch, unnecessary boxing, etc.)
click Inspect
Review proposed refactoring suggestions and click Do Refactoring
Your complete code base is refactored and uses your selected new features and new idioms.
IntelliJ IDEA has a similar feature. See Analyze > Inspect Code ...
In Eclipse this is called clean up in code style (configuration) or source (menu).
I have two Java artifacts being built. One needs to be built in 1.6, because PowerMock isn't compatible w/ 1.7 and we are using it in a lot of unit tests. Refactoring PowerMock out right now isn't an option as it will take too much time.
However, I want to use this artifact in a Java application built in 1.7 and run the whole thing in 1.7. I think that it should be Ok since it is just building some class files, which I doubt changed much if any probably as far back as 1.2 or earlier. Anyway, I obviously have a fuzzy understanding of this and I am interested to get a Java experts deep dive explanation as to when this would matter, when it wouldn't, and why.
Thanks!
Java is usually backwards compatible between versions so anything compiled on an old version should run fine on a newer JVM. In fact a lot of common libraries are compiled in as old a version as possible (usually Java 5 now a days) unless they need a newer feature to allow more people who are still stuck on old JVMs.
Having said that, there are a few gotchas you need to worry about. One problem I had on some Java 6 to 7 conversion was TreeMap with an initial value of null http://hariharanselvarajan-java.blogspot.com/2013/02/treemap-in-java-6-and-java-7.html
EDIT
Here is a link to Oracle discussing what isn't compatible between 6 and 7 although I would imagine this only affects things that are recompiled: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
The compiled code should be backwards compatible, so if you run it all on java7 it shouldn't matter than some was compiled using java6.
When you try the other way you get an invalid major/minor version number error.
I would assume that you can mix & match java 6 and 7 code too, just as you can (with caution) mix and match pre & post generics java.
I am experiencing numerous problems with java in MatLab 2013a, for example while using pmode, matlabpool, creating stand alone applications etc.
Sometimes there is a work-around but this is not always the case.
Does anybody has a solution for this problem. Is there a patch or a downgraded java version that works for you?
I believe that this is a different Java disaster from the one #JamesGrammatikos pointed out. I had to figure it out myself on R2012b. See this bug report at the MathWorks. To apply the workaround, read everything and follow the directions carefully as they didn't exactly try hard to make the patch into any sort of installer. Once, applied, everything works again, but looking at the patch code, there's still room for other stuff to break.
A Java update last month ago pretty much destroyed most Java based programs on Macs (including Matlab for me). The update at this link fixed it for me.
http://support.apple.com/kb/DL1572 (OS X 10.7, 10.8+)